TLS - Transport Layer Security

TLS ist ein Protokoll, das der Authentifizierung und Verschlüsselung von Internetverbindungen dient. TLS schiebt sich als eigene Schicht zwischen TCP und den Protokollen der Anwendungs- und Darstellungsschicht. In der Regel geht es darum, die Echtheit des kontaktierten Servers durch ein Zertifikat zu garantieren und die Verbindung zwischen Client und Server zu verschlüsseln.

Obwohl man in der Regel TLS verwendet, ist die Bezeichnung SSL immer noch üblich. Häufig werden beide Bezeichnungen synonym verwendet.

• SSL - Secure Socket Layer

TLS (Version 1.0) hat seinen Ursprung in SSL, das von Netscape in den 1990er Jahren für den Browser "Netscape Navigator" entwickelt wurde. Die Weiterentwicklung von SSL wurde mit der Version 3 beendet. Danach übernahm die IETF (Internet Engineering Task Force) die Weiterentwicklung und Normierung. Daraus entstand 1999 der Standard TLS (Transport Layer Security).
TLS ist bis auf ein paar Details mit SSL identisch. Die Unterschiede zwischen TLS Version 1 und SSL Version 3 reichen jedoch aus, dass beide zueinander inkompatibel sind. TLS verwendet zur Authentifizierung der Daten HMAC und erzeugt die Schlüssel mit der Funktion PRF.

Als Mindeststandard schreibt das BSI, als für die Sicherheit der bundesbehördlichen IT-Systeme zuständige Behörde, TLS 1.3 oder TLS 1.2 mit Diffie-Hellman-Schlüsselaustausch vor.

• TLS Version 1.3

TLS im OSI-Schichtenmodell

Im OSI-Schichtenmodell ist TLS auf Schicht 5, der Sitzungsschicht angeordnet. Im DoD-Schichtenmodell, das für TCP/IP verwendet wird, ist TLS auf der Transportschicht als Transportverschlüsselung über TCP und unterhalb der Anwendungsprotokolle zugeordnet. Dabei arbeitet TLS völlig transparent. So können theoretisch alle denkbaren Anwendungsprotokolle TLS zum Verschlüsseln benutzen. Dabei muss aber jedes Anwendungsprotokoll TLS explizit beherrschen.
So wird beispielsweise aus dem unverschlüsselten HTTP (Hypertext Transfer Protocol) das verschlüsselte HTTPS (Hypertext Transfer Protocol Secure). Ebenso ist es möglich E-Mails über TLS beim POP-Server verschlüsselt abzurufen oder an den SMTP-Server verschlüsselt zu übermitteln. Auch hier bekommen die Protokolle einen "Secure"-Zusatz (SMTPS, POPS, IMAPS).
TLS ist inzwischen nicht nur auf HTTPS oder andere Kommunikationsprotokolle beschränkt. Verfahren wie EAP-TLS, EAP-TTL, PEAP und auch das LDAP-Protokoll verwenden TLS.

Anwendungsbeispiel: HTTPS

TLS ist eine optional aktivierbare Sicherheitskomponente für HTTP und ist somit für Webseiten gedacht, die vertrauliche Daten verarbeiten. Zum Beispiel beim Online-Banking oder Online-Shopping. Diese Webseiten bauen in der Regel automatisch eine verschlüsselte Verbindung zwischen Browser und Webserver auf. Der User bekommt das nur mit, wenn ein Schloss- oder Schlüssel-Symbol in der Statusleiste eingeblendet wird oder die Adresszeile ihre Farbe ändert.

• HTTPS / HTTP Secure

Funktionsweise von TLS

Bestandteil von TLS ist die Zertifizierung (1.) des öffentlichen Schlüssels, die Authentifizierung des Servers (2.), die Validierung des übermittelten Zertifikats (3.) und die anschließende verschlüsselte Übertragung von Daten zwischen Sender und Empfänger.
Für die Authentifizierung werden Zertifikate verwendet. Unter anderem um das Verteilungsproblem von Authentifizierungsinformationen zu beheben und um Identitäten zu authentifizieren. Hierbei geht es darum, die Authentizität der Gegenstelle zweifelsfrei feststellen zu können, um nicht mit einer falschen Gegenstelle eine Verbindung einzugehen.

Zertifikate

Eine Verschlüsselung besteht aus der Verschlüsselung der Daten beim Sender und der Entschlüsselung der Daten beim Empfänger. Bei TLS arbeitet man mit zwei unterschiedlichen Schlüsseln zur Ver- und Entschlüsselung. Das sogenannte Schlüsselpaar besteht aus einem privaten (Private Key) und einem öffentlichen Schlüssel (Public Key). Der öffentliche Schlüssel des Empfängers ist dem Sender bekannt. Er benutzt ihn zum Verschlüsseln der Daten. Anschließend können die verschlüsselten Daten aber nicht mehr mit dem öffentlichen Schlüssel entschlüsselt werden. Dafür braucht es den privaten Schlüssel, der nur dem Empfänger bekannt sein darf und deshalb zwingend geheim gehalten werden muss. Nur der Server mit dem passenden privaten Schlüssel ist in der Lage die verschlüsselten Daten zu entschlüsseln (asymmetrisches Verschlüsselungsverfahren bzw. Public-Key-Verfahren).

Bevor nun der Sender Daten verschlüsseln darf, muss er jedoch zweifelsfrei feststellen, ob der öffentliche Schlüssel, den er vom Empfänger mitgeteilt bekommt, auch tatsächlich dem Empfänger gehört, dem er die Daten verschlüsselt schicken will. Eine per TLS verschlüsselte Verbindung bietet keinen Schutz, wenn nicht sichergestellt ist, dass der öffentliche Schlüssel von dem Server kommt, zu dem eine verschlüsselte Verbindung hergestellt werden soll.
An der Stelle kommt jetzt das Zertifikat ins Spiel, mit dem sich ein Server und sein öffentlicher Schlüssel authentisieren. Um die Gültigkeit des öffentlichen Schlüssels zu unterstreichen, lässt sich der Server-Betreiber und Domain-Inhaber ein Zertifikat ausstellen, in dem unter anderem Domainname, der öffentliche Schlüssel, ein Ablaufdatum enthalten sind und welche Instanz die Vertrauenswürdigkeit bestätigt hat.
Durch das Zertifikat authentisiert sich der Empfänger gegenüber dem Sender bzw. der Server gegenüber dem Client. Gleichzeitig kann der Client das Zertifikat überprüfen (Validierung) und somit die Vertrauenswürdigkeit feststellen (Authentizität).

TLS arbeitet mit PKIX-Zertifikaten bzw. mit einer Public Key Infrastructure nach X.509v3. Die Zertifikate koppeln eine Identität an einen öffentlichen Schlüssel, der zur Authentifizierung und Verschlüsselung verwendet wird.
Es gibt insgesamt drei Zertifikatstypen, die sich durch einen unterschiedlichen Prüfaufwand bei der Zertifizierung unterscheiden und so eine entsprechend unterschiedliche Echtheitsstufe garantieren.

• Domain-Validated-Zertifikat (DV)
• Organisation-Validation-Zertifikat (OV)
• Extended-Validation-Zertifikat (EV)

Die häufigsten Zertifikate sind DV- und EV-Zertifikate. Während man DV-Zertifikate schon für wenige Euro oder sogar kostenlos bekommen kann, kommen wegen des erheblichen Prüfaufwands bei EV-Zertifikaten mehrere hundert oder sogar tausend Euro zusammen. Allerdings kann man bei EV-Zertifikaten von einer höheren Vertrauenswürdigkeit ausgehen.

Welches Zertifikat bei einer verschlüsselten Verbindung zum Einsatz kommt, ist als Nutzer nicht so leicht zu erkennen. Meist ist eine verschlüsselte Verbindung in einem Client nur an einem Schloss-Symbol zu erkennen. Aber nicht, um was es sich für ein Zertifikat handelt.
Zertifikate werden von einer Zertifizierungsstelle bzw. Certification Authority (CA) ausgestellt und beglaubigt.

Certificate Authority (CA) / Zertifizierungsstelle

Weltweit gibt es weit über 700 Zertifizierungsstellen. Im Englischen auch Certificate Authority oder Certification Authority genannt. Meist mit CA abgekürzt.
Die Certificate Authorities (CA) sind ein wichtiger Pfeiler für die Sicherheit im Internet. Jeder, der sichere Dienste im Internet anbietet, lässt sich die Echtheit von digitalen Schlüsseln und Signaturen von einer Certificate Authority bestätigen.

Dazu lässt sich ein Unternehmen oder eine Organisation von einer Certificate Authority nach einer Überprüfung ein digitales Zertifikat ausstellen. Das kann dann zum Beispiel auf einem Webserver hinterlegt werden. Mit diesem Zertifikat weist sich die Webseite gegenüber den zugreifenden Browsern als Eigentümer aus. Der Browser des Besuchers überprüft die Angaben im Zertifikat und fragt bei Bedarf bei der ausstellenden Zertifizierungsstelle nach, ob das Zertifikat gültig ist.
Auf diese Weise können zum Beispiel die Kunden einer Bank davon ausgehen, dass sie tatsächlich mit dem Server der Bank verbunden sind und das der Datenaustausch verschlüsselt erfolgt, wenn sie Online-Banking betreiben.

Auch die Zertifizierungsstelle besitzt ein Zertifikat, indem sich deren öffentlicher Schlüssel befindet. Dabei handelt es sich um ein Wurzel- bzw. Stammzertifikat, das in Browsern und Betriebssystemen hinterlegt ist. Diesen Stammzertifikaten wird in der Regel bedingungslos vertraut. Anhand der Signatur der Zertifizierungsstelle und dem Stammzertifikat kann ein Browser feststellen, ob das Zertifikat einer Domain wirklich von der angegebenen Zertifizierungsstelle ausgestellt wurde.

Das Geschäftsverhältnis zwischen Zertifizierungsinstanz und den Unternehmen, aber auch zu den Internet-Nutzern, beruht auf Vertrauen. Daher muss eine CA alles dafür tun, dass die Prüfprozesse ordnungsgemäß funktionieren und sicher vor Manipulationen sind.
Leider ist es schon vorgekommen, dass Eindringlinge auf interne Server von Zertifizierungsstellen zugegriffen und sich dort Zertifikate generiert haben. Wird ein solches Zertifikat verwendet, kann ein Internet-Nutzer einen Betrug nicht überprüfen. Und ein Unternehmen, dass Dienste im Internet anbietet, kann genauso wenig feststellen, ob eine Zertifizierungsstelle unberechtigt Zertifikate ausgestellt hat. Höchstens die CA kann betrügerische Zertifikate feststellen.
CAs sind also Treuhänder, die nur von ihrem guten Ruf leben. Sobald bekannt wird, dass eine CA Schindluder betreibt oder gehackt wurde, kann sie den Laden schließen.

Zertifizierung

Das Zertifikat wird von einer Zertifizierungsstelle, auch Certificate Authority (CA) genannt, ausgestellt. Die Zertifizierungsstelle signiert das Zertifikat mit ihrem eigenen privaten Schlüssel, womit die Echtheit der Daten bestätigt sind. Im Vorfeld prüft die Zertifizierungsstelle die Informationen im Zertifikat und die Identität des Antragstellers. Dafür gibt es verschiedene Verfahren. Beispielsweise den Certificate Signing Request (CSR).

CSR - Certificate Signing Request / Antrag zur Zertifizierung

Der Certificate Signing Request (CSR) ist ein gängiges Verfahren, um sich seinen öffentlichen Schlüssel von einer Zertifizierungsstelle signieren zu lassen. Davor erzeugt sich der Server-Betreiber ein Schlüsselpaar auf dem eigenen Server. Beispielsweise mit OpenSSL. Manche Zertifizerungsstellen sind auch in der Lage aus der Ferne die Schlüsselerzeugung auf dem Rechner des Kunden anzustoßen. Dafür bringen die Browser die notwendigen Kryptografieverfahren mit.
Der CSR bzw. der Antrag des Zertifikats erfolgt dann zum Beispiel per Webformular. Dabei muss man Angaben machen, die von der Zertifizierungsstelle geprüft und in das Zertifikat eingetragen werden. Nach der Ausstellung des Zertifikats kann der Kunde das Zertifikat und den privaten Schlüssel auf dem jeweiligen Server ablegen.

1. Der Server-Betreiber erzeugt ein Schlüsselpaar, bestehend aus einem öffentlichen und privaten Schlüssel. Der private Schlüssel bleibt auf dem Server und wird geheim gehalten.
2. Der Server-Betreiber stellt einen CSR für den öffentlichen Schlüssel an eine CA.
3. Die CA prüft die Angaben des CSR und den öffentlichen Schlüssel.
4. Ist alles korrekt, erstellt die CA ein Zertifikat und schickt es an den Server-Betreiber zurück.

Validierung eines Zertifikats

Bekommt ein Client oder Server von einem anderen Server ein Zertifikat, dann muss er sich von dessen Echtheit überzeugen. Also, ob das Zertifikat wirklich von dem Server kommt, der kontaktiert wurde.
Mit der Validierung eines Zertifikats wird die Identität bestätigt, ohne dass die beteiligten Kommunikationspartner vorab Authentifizierungsinformationen, wie zum Beispiel Schlüssel, austauschen müssen.

Im folgenden Beispiel wird die Validierung exemplarisch für eine verschlüsselte HTTPS-Verbindung beschrieben. Grundsätzlich funktioniert die Validierung bei anderen Protokollen genauso.
Nachdem der Browser vom Webserver ein Zertifikat bekommen hat, beginnt er mit der Validierung. Der Browser prüft zuerst, ob er dem Aussteller des Zertifikats, der Zertifizierungsstelle oder Certificate Authority (CA), vertraut. Dazu muss das entsprechende Wurzelzertifikat der Zertifizierungsstelle im Browser hinterlegt sein (1. und 2.). Der Browser hat dazu eine Liste mit Zertifizierungsstellen, denen er per Default vertraut.
Im zweiten Schritt kontaktiert der Browser die angegebene Validierungsstelle bzw. Zertifizierungsstelle (3. und 4.). Diese prüft, ob das Zertifikat gültig ist und meldet das Ergebnis an den Browser zurück.
Sofern das Zertifikat bereits bekannt ist, ist eine Validierung über die Zertifizierungsstelle nicht mehr zwingend erforderlich.

Ablauf der Authentifizierung

Beim ersten HTTPS-Request durch den Browser (Client) nutzt TLS die asymmetrische Verschlüsselung. Der Server schickt als erste Antwort seinen öffentlichen Schlüssel (Public Key) und ein Zertifikat. Auf diese Weise authentisiert sich der Webserver gegenüber dem Client. Schlüssel und Zertifikat werden vom Client auf Glaubwürdigkeit überprüft. Je nach Einstellung des Clients muss der Benutzer zuerst die Glaubwürdigkeit bestätigen.
Nach erfolgreicher Authentifizierung des Servers, generiert der Browser einen symmetrischen Schlüssel, den er mit dem öffentlichen Schlüssel des Servers verschlüsselt. Den symmetrischen Schlüssel schickt der Browser dann an den Server. Der Server kann das verschlüsselte Paket mit seinem privaten Schlüssel öffnen. Der darin enthaltene Schlüssel des Browsers nutzt der Server für die symmetrische Verschlüsselung der darauf folgenden Verbindung. Eine sichere Übertragung ist gewährleistet. Die Inhalt der HTTPS-Pakete sind gegen Belauschen und Veränderung geschützt.
Während der Datenübertragung zwischen Client und Server wird immer wieder ein neuer Schlüssel ausgehandelt, so dass ein möglicher Angreifer nur für eine kurze Zeit die Verbindung stören kann.

In der Regel authentifiziert sich der Client nicht. Die Möglichkeit der beiderseitigen Authentifizierung per Signatur ist als Option in der TLS-Spezifikation enthalten. In der Regel muss nur bei einem SSL-VPN auch der Client seine Identität mit einem Zertifikat ausweisen.
Die Benutzerauthentifizierung, sofern erforderlich, findet in der Regel auf der Anwendungsebene statt. Konkret bedeutet dass, der Kunden würde sich in einem Online-Shop registrieren und anmelden oder im Online-Banking mit Pin, Passwort und TAN identifizieren.

eTLS - Enterprise TLS

Das europäische Institut für Telekommunikation, kurz ETSI, hat eine Variante von TLS 1.3 standardisiert. Enterprise TLS, kurz eTLS, beinhaltet eine absichtliche Schwächung des Verschlüsselungsstandards Transport Layer Security (TLS). eTLS enthält die Möglichkeit Nachschlüssel vorzuhalten, die es Unternehmen oder Strafverfolgern ermöglichen, verschlüsselten Datenverkehr aufzubrechen. Dadurch können Unternehmen, Dienstanbieter und Netzbetreiber ihren gesetzlichen Verpflichtungen zur Sicherung und Überwachung ihrer Netze nachkommen.

Mit eTLS arbeiten Server mit statischen Diffie-Hellman-Schlüsseln, die sie über einen längeren Zeitraum nutzen und in regelmäßigen Abständen an Middle-Boxen übermitteln, damit die den Datenverkehr mitlesen können. Der Client muss dabei nicht mitwirken. Er muss nur TLS 1.3 können.

eTLS soll ausschließlich innerhalb von Firmennetzen zum Einsatz kommen.

Implementierungen von SSL bzw. TLS

• Betriebssysteme
• Browser
• Bibliotheken

Beim Einsatz von Implementierungen für TLS sollte man auf bewährte Lösungen setzen. Die Vertrauenswürdigkeit der Implementierungen drückt sich dadurch aus, dass der Quellcode öffentlich ist. Dass man also prinzipiell die Möglichkeit hat den Quellcode auf Fehler und Hintertüren zu überprüfen. Zwar lässt sich bei bekannten und beliebten Bibliotheken nicht ausschließen, dass sie trotzdem Fehler und Lücken enthalten. Trotzdem ist hier die Wahrscheinlichkeit größer, dass doch mal jemand auf den Quellcode schaut. Es spielt durchaus auch eine Rolle, wie aktiv eine Software oder ein Produkt gepflegt wird.

Wie sicher ist SSL bzw. TLS?

Seit den Enthüllungen im Rahmen des NSA-Skandals im Sommer 2013 ist bekannt, dass TLS definitiv unsicher ist und eine unsichere Authentifizierung enthält, was zu einer nur bedingt wirksamen Verschlüsselung führt. Das Problem dabei ist nicht die Verschlüsselung an sich, sondern das Vertrauenskonzept, welches hierarchisch angeordnet ist.
Ein Geheimdienst, wie die NSA, der Google, Microsoft, Yahoo und Apple zur Zusammenarbeit zwingen kann, kann das auch bei einer Zertifizierungsstelle, wie sie bei TLS die zentrale Instanz für die Zertifizierung und Validierung von Identitäten bildet. Und deshalb gelten Zertifizierungsstellen, denen man bedingungslos vertrauen muss, als kompromittiert.

TLS ist also nicht wirklich sicher! Trotzdem kann man TLS als sicher ansehen. Doch das bedeutet nicht, dass es für alle Anwendungen und in Zukunft sicher genug ist. Das bedeutet, trotz Authentifizierung und Verschlüsselung muss man als Nutzer mit einer gewissen Unsicherheit leben.

Für die meisten Anforderungen sind TLS ausreichend sicher. Zwar gab es immer wieder Sicherheitsprobleme, die nur zum Teil ausgemerzt werden. Die meisten davon lassen sich aber nur durch gezielte Angriffe ausnutzen, was zusätzlich mit einem großen Aufwand verbunden ist. Für die Massenüberwachung sind die meisten Angriffe auf TLS ungeeignet und mit einem gewissen Entdeckungsrisiko verbunden. Wirklich erfolgreich sind nur die Angriffe, die auf dem Unterschieben falscher Zertifikate basieren, die jeder Browser als gültig akzeptiert. Dass das CA-Modell für die Authentifizierung kaputt ist, ist schon länger bekannt und wir leben schon seit vielen Jahren damit. Lösungen gegen dieses Problem gibt es. Die setzen sich aber nur sehr langsam durch.

• Schwachstellen von SSL und TLS
• Verschlüsselung prüfen

TLS sicherer machen

Hinweis: Mit dem aktuellen Vertrauensmodell (Certificate Authority) ist es unmöglich die Authentifizierung und Verschlüsselung für alle Anwendungen sicher zu machen. Die einzige Möglichkeit besteht darin, Workarounds zu bauen, also Teilprobleme von TLS und dessen kaputtes Vertrauensmodell zu lösen, um die Sicherheit des System einigermaßen glaubhaft am Laufen zu halten.

• OCSP - Online Certificate Status Protocol
• HPKP - HTTP Public Key Pinning
• CT - Certificate Transparency
• CA-Pinning / Certification Authority Authorization
• DANE - DNS-based Authentication of Named Entities

Weil die Authentifizierung grundsätzlich defekt ist, versucht man wenigstens die Verschlüsselung so weit hinzubekommen, dass die Kommunikation rückwirkend nicht entschlüsselt werden kann. Diese Maßnahmen sind erforderlich, weil man weiß, dass Geheimdienste (bspw. die NSA) verschlüsselten Datenverkehr aufzeichnet. Anschließend versuchen Geheimdienste über offizielle Anordnungen die Herausgabe der Schlüssel zu fordern oder sich den Zugang zu den Schlüsseln anderweitig zu beschaffen.
Mit dem Einsatz von Perfect Forward Secrecy in Kombination mit Diffie Hellman kann man die Kommunikation rückwirkend nicht entschlüsseln. Deshalb wird für die verschlüsselte Übertragung von personenbezogenen oder anderen sensiblen Daten mit TLS Perfect Forward Secrecy und Diffie-Hellman empfohlen.

• PFS - Perfect Forward Secrecy

Um TLS sicherer zu betreiben führt ebenfalls kein Weg an TLS Verion 1.3 vorbei.

• TLS Version 1.3

Übersicht: TLS

• TLS - Transport Layer Security
• Schwachstellen von SSL und TLS
• Analyse von SSL- und TLS-Verbindungen
• HTTPS / HTTP Secure

Weitere verwandte Themen:

• Grundlagen der Netzwerk-Sicherheit
• Sicherheitskonzepte in der Informations- und Netzwerktechnik
• Hybride Verschlüsselungsverfahren
• Kryptografische Verfahren und ihre Sicherheit (Übersicht)

Netzwerktechnik-Fibel

Alles was Sie über Netzwerke wissen müssen.

Die Netzwerktechnik-Fibel ist ein Buch über die Grundlagen der Netzwerktechnik, Übertragungstechnik, TCP/IP, Dienste, Anwendungen und Netzwerk-Sicherheit.

Das will ich haben!

Artikel-Sammlungen zum Thema Netzwerktechnik

Collection: Netzwerk-Sicherheit

Was du über Netzwerk-Sicherheit wissen solltest.

eBook kaufen

Collection: Netzwerk-Grundlagen

Was du über Netzwerk-Grundlagen wissen solltest.

eBook herunterladen

Collection: IPv6

Was du über IPv6 wissen solltest.

eBook kaufen

Schützen Sie Ihr Netzwerk

Die TrutzBox enthält einen leistungsstarken Content-Filter, der Werbetracker blockiert und vor Schadcode auf bösartigen Webseiten schützt.
Alle Internet-fähigen Geräte, egal ob Desktop-PCs, vernetzte Produktionsanlagen und IoT-Geräte, werden vor Überwachung durch Tracker, Einschleusen von Schadsoftware und dem unbedachten Zugriff auf bösartige Webseiten geschützt.

• Sicheres Surfen mit Content-Filter und Blocker gegen Werbetracker
• Mehrstufige Sicherheitsarchitektur mit Stateful-Inspection-Firewall und Intrusion-Prevention-System
• Laufende Aktualisierung gegen neue Bedrohungen

Bestellen Sie Ihre TrutzBox mit integriertem Videokonferenz-Server jetzt mit dem Gutschein-Code "elko50" und sparen Sie dabei 50 Euro.

Mehr über die TrutzBox TrutzBox jetzt mit Gutschein-Code bestellen