
Das Protokoll wurde ursprünglich als Secure Sockets Layer bezeichnet. Mit der Einführung von TLS 1.0 wurde die Bezeichnung Transport Layer Security eingeführt. Die Bezeichnungen TLS und SSL werden in der Praxis häufig synonym verwendet. Die Protokollversionen SSL 1.0-3.0 sowie TLS 1.0 und 1.1 sind jedoch veraltet und unsicher und sollten nicht mehr genutzt werden. Die aktuelle Version des Protokolls ist TLS 1.3.
TLS verbindet asymmetrische und symmetrische Verschlüsselungsverfahren (hybrides Verschlüsselungsprotokoll), um zwei Parteien eine verschlüsselte Kommunikation über ein Netzwerk zu ermöglichen. Werden Inhalte beim Transfer nicht verschlüsselt, besteht die Möglichkeit, dass andere Teilnehmer (z. B. Betreiber des Netzwerks oder andere Parteien mit Zugriff auf den Datenverkehr) diese Inhalte mitlesen oder verändern.
Damit die Kommunikation als sicher gilt, muss mindestens einer der Kommunikationspartner mittels eines asymmetrischen Kryptoverfahrens seine Identität bestätigen. Bei Kommunikation im Internet ist dies in der Regel der Server. Hierzu werden üblicherweise sog. Public-Key-Zertifikate eingesetzt. Diese bestätigen die Identität und Eigenschaften eines öffentlichen Schlüssels des Zertifikatsinhabers, sofern das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle ausgegeben und beglaubigt wird. Für diesen Schritt wird in den meisten Fällen das Kryptosystem RSA eingesetzt.
Nachdem die Authentifizierung durch die Prüfung des Zertifikats erfolgt ist, kommt erneut ein asymmetrisches Kryptoverfahren zum Einsatz, durch das die Partner einen gemeinsamen, geheimen Schlüssel vereinbaren, der dann für die weitere Verschlüsselung des Datenverkehrs genutzt werden kann. In der Regel kommt hier das Diffie-Hellman-Protokoll zum Einsatz. Der Diffie-Hellman-Schlüsselaustausch erlaubt es den Kommunikationsteilnehmern, durch den Austausch nicht verschlüsselter Daten aus diesen Daten einen gemeinsamen Schlüssel zu errechnen. Beide Partner haben dabei einen jeweils unterschiedlichen privaten Teil als Basis für den Schlüsselaustausch. Diese private Information wird nicht übertragen und muss unbedingt geheim bleiben. Ein potenzieller Angreifer kann die öffentlichen Informationen, die für die Vereinbarung des geheimen gemeinsamen Schlüssels genutzt werden, nicht dazu nutzen, den gemeinsamen, geheimen Schlüssel zu errechnen oder in realistischer Zeit zu erraten.
Das Diffie-Hellman-Protokoll ist deshalb besonders beim Einsatz für die Verschlüsselung von Inhalten im Internet über den Standard Https nützlich, weil die üblichen Kommunikationspartner in diesem Kontext, ein Webserver und ein Client (bzw. dessen Internetbrowser) in der Regel keine Informationen übereinander besitzen und somit auch im Vorfeld keinen gemeinsamen Schlüssel besitzen können, mit dem sie Inhalte symmetrisch verschlüsseln könnten.
Sobald ein gemeinsamer geheimer Schlüssel vereinbart wurde, kann dieser dazu genutzt werden die eigentlichen Inhalte der Kommunikation zu verschlüsseln, um sie danach zu übermitteln. Hierzu kann ein symmetrisches Verschlüsselungsverfahren genutzt werden. Bei diesen Verfahren werden Inhalte mit einem Schlüssel sowohl verschlüsselt und entschlüsselt, die Verschlüsselung ist deshalb umkehrbar und somit symmetrisch. Das derzeit am meisten verbreitete symmetrische Kryptosystem ist der Advanced Encryption Standard (AES) mit diesem können Informationen mit Schlüsseln der Länge 128 Bit (AES-128), 192 Bit (AES-192) und 256 Bit (AES-256) verschlüsselt werden. Je länger der genutzte Schlüssel ist, desto sicherer ist die Verschlüsselung. Dieser Algorithmus wird auch bei TLS häufig verwendet, es ist jedoch auch der Einsatz anderer Verschlüsselungsverfahren möglich.
Für TLS gibt es verschiedene sog. Cipher Suites (Chiffrensammlungen) die den Einsatz bestimmter Verschlüsselungs- und Authentifizierungsverfahren standardisieren. Diese Suites geben vor, welche Verfahren für die folgenden Schritte des Protokolls verwendet werden:
Beispiel Cipher Suite:
ECDHE–RSA–AES256-GCM–SHA384
Im Rahmen des TLS-Handshakes einigen sich die Kommunikationspartner auf eine Chiper Suite, die dann in der Folge verwendet wird.
Mit dem aktuellen Standard des Protokolls TLS 1.3 wurde ein Teil des Protokolls fest definiert. Für den Schlüsselaustausch muss das Elliptic Curve Diffie-Hellmann Ephemeral-Verfahren genutzt werden. Dies hat den Vorteil, dass sog. „forward secrecy“ gegeben ist, weil der erzeugte Schlüssel für nur jeweils eine Session gültig ist. Wird also ein einzelner Schlüssel bekannt, lässt sich mit diesem höchstens die Kommunikation einer einzelnen Session entschlüsseln und nicht der gesamte bis dahin ausgetauschte Datenverkehr. Durch diese Festlegung auf das Verfahren für den Schlüsselaustausch kann der TLS-Handshake schneller ablaufen.
Eine weitere Änderung durch die Version 1.3 ist eine starke Reduktion der zugelassenen Cipher Suites. Während es bei Version 1.2 noch 293 verschiedene Suites gab, die zum Teil unsicher sind, gibt es in der Version 1.3 derzeit nur noch 5 zugelassene Suites, die aktuell alle als sicher gelten. Das vereinfacht die Auswahl der genutzten bzw. akzeptierten Suites stark.
Beispiel Cipher Suite: TLS 1.3:
TLS_AES_256_GCM_SHA384
TLS wird für eine verschlüsselte Übertragung verschiedener Protokolle genutzt. Das bekannteste Beispiel ist HTTPS die verschlüsselte Variante des Hyper Text Transfer Protocol (HTTP). Dieses wird beispielsweise beim verschlüsselten Abruf von Webseiten genutzt. Bei der Übertragung sensibler Daten, wie Log-in-Formularen, ist die Nutzung einer TLS-Verschlüsselung häufig Pflicht. Moderne Browser warnen zudem davor, wenn solche Daten aus Formularen ohne Verschlüsselung übertragen werden sollen.
Weitere Einsatzfelder sind die Protokolle POP3S, SMTPS oder IMAPS bei der Übertragung von E-Mails oder SIPS für eine verschlüsselte Übertragung von VOIP-Kommunikation. Es gibt noch zahlreiche weitere Anwendungen für TLS.
In den letzten zehn Jahren hat der Einsatz von TLS bzw. SSL stark zugenommen. Mittlerweile wird im World Wide Web ein großer Teil von Webseiten über TLS/HTTPS abgesichert. Dies hat einen positiven Effekt für Datenschutz und IT-Sicherheit der Nutzer des Internets.
Hierbei sollte jedoch beachtet werden, dass in den meisten Fällen keine Ende-zu-Ende-Verschlüsselung besteht, weil durch SRTP nur eine verschlüsselte Verbindung von einem Endgerät zum Service-Provider (z. B. dem Telefonanbieter) gewährleistet werden kann. Der Nutzer hat keinen Einfluss darauf, ob der Provider die Datenübertragung zum Empfänger in der Folge ebenfalls verschlüsselt. Mindestens beim Provider findet eine Entschlüsselung der Daten statt. Die Möglichkeit, Daten zu entschlüsseln und somit einzusehen und auszuwerten ist hierbei häufig gewünscht.
So sieht etwa in Deutschland das TKG (Telekommunikationsgesetz) die Möglichkeit vor, dass Strafverfolgungsbehörden unverschlüsselte Kommunikationsdaten anfordern und einsehen können. Telekommunikationsdienstleister sind gesetzlich dazu verpflichtet, diese Möglichkeit der Einsicht in Kommunikation zu ermöglichen.
Wir verwenden Cookies, und Google reCAPTCHA, das Google Fonts lädt und mit Google-Servern kommuniziert. Durch die weitere Nutzung unserer Website stimmen Sie der Verwendung von Cookies und unserer Datenschutzerklärung zu.