WikiDer > Transportschichtsicherheit

Transport Layer Security

Transportschichtsicherheit (TLS) und sein Vorgänger Secure Sockets Layer (SSL), sein Verschlüsselung-Protokolle dass die Kommunikation zwischen Computers (zum Beispiel auf der Internet) absichern. TLS wird normalerweise ausgesprochen "tie-el-es".

Ziele

Der Zweck der TLS-Protokolle ist zweifach.

Der Grund für die Verwendung zweier getrennter kryptographischer Verfahren, asymmetrisch und symmetrisch, liegt darin, dass ersteres relativ zeitaufwendig und daher für den Austausch großer Datenmengen nicht geeignet ist.

Im alltäglichen Einsatz von TLS wird lediglich die Authentizität des Servers überprüft, während der Client völlig unbekannt bleibt. Es ist auch möglich, den Client über TLS zu authentifizieren, dies geschieht jedoch nur bei einigen bestimmten Anwendungen. Die Protokolle können auch verwendet werden, um Kundenserversichere Anwendungen.

Anwendung

TLS wird hauptsächlich in Situationen verwendet, in denen überprüft werden muss, ob tatsächlich eine Verbindung zum gewünschten Server besteht. Dies ist insbesondere bei Bankanwendungen (Internetbanking) oder der Kommunikation mit der Regierung wichtig, da oft finanzielle Interessen auf dem Spiel stehen oder persönliche oder anderweitig vertrauliche Informationen ausgetauscht werden.

In vielen Fällen basiert diese Sicherheit auf a Public-Key-Infrastruktur (meist X.509) bereitgestellt von a Zertifizierungsstelle (CA) wird unterstützt. In der jüngsten Vergangenheit haben sich jedoch mehrere CA-Unternehmen als weniger zuverlässig als nötig erwiesen, was das Vertrauen in diesen Ansatz untergräbt. Vor allem das Debakel drumherum DigiNotar spielten dabei in den Niederlanden eine große Rolle, aber auch Fälle von Schurke CAs sind bekannt und haben international für Aufsehen gesorgt.[1]

SSL und TLS sind in vielen implementiert kostenlose und Open-Source-SoftwareProjekte. Programmierer können unter anderem für SSL- und TLS-Funktionalität verwenden: PolarSSL, CyaSSL, OpenSSL, NSS und GnuTLS.

Geschichte und Entwicklung

Den ersten Impuls gab die Sichere NetzwerkprogrammierungAPI die gängige Netzwerk-APIs (insbesondere Berkeley Sockets) genau nachahmte, um die Entwicklung sicherer Netzwerksoftware zu vereinfachen.

SSL 1.0, 2.0 und 3.0

Secure Sockets Layer wurde 1994 von . entwickelt Netscape Communications Corporation basierend auf Kerberos Sicherheitsprotokoll, als ein Protokoll, das dauerhafte und sichere Transaktionen ermöglicht. Die erste Version von SSL 1.0 wurde nie der Öffentlichkeit zugänglich gemacht, aber Version 2.0 wurde 1995 veröffentlicht. Diese Version zeigte bald kryptografische Schwächen und wurde 1996 vom komplett neu geschriebenen Protokoll SSL 3.0 gefolgt. Diese Version wurde veröffentlicht von der IETF erschienen 2011 als historisches Dokument in RFC 6101.[2]

Alle drei Versionen sind als unsicher einzustufen, da die Schwachstelle POODLE im Oktober 2014 bekannt wurde[3].

TLS 1.0

Im Jahr 1999, RFC 2246, das TLS 1.0 beschrieb.[4] Die Unterschiede zu SSL 3.0 sind laut den Autoren der RFC, nicht dramatisch, aber genug, um die Interoperabilität zwischen den beiden zu verhindern. TLS 1.0 enthält einen sogenannten Fallback-Mechanismus, der eine Verbindung zu SSL 3.0 ermöglicht.

Diese Version hat, obwohl sie die am weitesten verbreitete ist, einige Schwächen. Zum Beispiel der symmetrische Verschlüsselungsalgorithmus RC4[5] und der kryptografische Hash MD5[6] als unsicher erwiesen.

Im Jahr 2011 wurde diese Version von Thai Duong und Juliano Rizzo geknackt, mit diesem Angriff auf TLS 1.0 namens BEAST[7], kann die Kommunikation zwischen zwei Teilnehmern in einem Netzwerk entschlüsselt werden. Der BEAST-Angriff nutzt eine bekannte Schwachstelle in TLS 1.0 aus, die bis dahin als praktisch unausnutzbar galt.[8] Im Jahr 2002, in OpenSSL Maßnahmen, die bereits ergriffen wurden, um die von BEAST verwendete Schwachstelle zu mindern[9], Als Antwort auf BEAST, Mozilla Firefox[10] Google Chrome[11], Internet Explorer[12] und nach langer Zeit auch in Apples Safari Browser[13] Anpassungen vorgenommen, die BEAST abschwächten. In der Praxis stellt der BEAST-Angriff keine Bedrohung mehr für die Vertraulichkeit von TLS 1.0-Verbindungen dar.

TLS 1.1

Im April 2006 wurde der Nachfolger von TLS 1.0 veröffentlicht, spezifiziert in RFC 4346.[14] Diese Version ist eine Weiterentwicklung der Version 1.0 und bietet mehrere Verbesserungen:

  • Schutz gegen Chiffrierblockverkettung angreifen:
  • Vorzeitig beendete Sitzungen können wieder aufgenommen werden.
  • Unterstützung von IANA Parameterregistrierung.

Diese Version ist nicht anfällig für den Angriff von Duong und Rizzo, wurde jedoch kaum verwendet, als der Angriff im Jahr 2011 entdeckt wurde.[7]

TLS 1.2

Im August 2008 wurde TLS 1.2 veröffentlicht, spezifiziert in RFC 5246.[15] Gegenüber TLS 1.1 wurden viele Verbesserungen vorgenommen, insbesondere im verwendeten kryptografischen System hashes, die sich als unsicher herausgestellt hatte[5][6] und wurden ersetzt durch SHA-256. Diese Version unterstützt auch modernere Verschlüsselungsverfahren aus dem fortgeschrittener Verschlüsselungsstandard. Im März 2011 wurde TLS 1.2 weiter verfeinert: mit RFC 6176[16] die Fallback-Kompatibilität mit dem unsicheren SSL 2.0 wurde entfernt.

TLS 1.3

Im März 2018 wurde TLS 1.3 veröffentlicht, spezifiziert in RFC 8446.[17] In TLS 1.3 wurden einige unsichere Algorithmen aus Version 1.2 fallengelassen. zusätzlich Händedruck vereinfacht.

Operation

Weil SSL/TLS implementiert ist als OSI-Transportschicht (daher der Name) seine Verwendung ist für das Anwendungsprotokoll weitgehend transparent. In der Praxis bedeutet dies, dass es für den http-Server oder den Browser keinen Unterschied macht, ob TLS verwendet wird oder nicht, das Anwendungsprotokoll (hier HTTP, aber auch andere Protokolle) ist das gleiche.

Sowohl TLS als auch SSL verwenden eine Reihe verschiedener Stufen:

Peer-Negotiation für Algorithmusunterstützung
In dieser Phase werden die verwendeten Verschlüsselungsmechanismen abgestimmt und unterstützte Versionen des Protokolls verglichen. Wird eine Inkompatibilität festgestellt, wird die Verbindung abgebrochen.
Auf Verschlüsselung mit öffentlichem Schlüssel basierender Schlüsselaustausch und zertifikatbasierte Authentifizierung
In dieser Phase werden verwendete Zertifikate verglichen und der (zufällige) Schlüssel für die Blockverschlüsselung mittels des Diffie-Hellman-Mechanismus vereinbart.
Symmetrische Chiffre-basierte Verkehrsverschlüsselung
Der Datenaustausch erfolgt auf Basis des vereinbarten Verschlüsselungsverfahrens und des vereinbarten Schlüssels.

Beschreibung

TLS basiert auf Secure Socket Layer (SSL). Ein Vorteil von TLS ist, dass es unabhängig vom Anwendungsprotokoll ist. Das Protokoll läuft oberhalb von Transportprotokollen (TCP/IP) und unter Anwendungsprotokollen wie HTTP oder IMAP. Bei der Kommunikation zwischen Server und Benutzer stellt TLS sicher, dass die Daten nicht abgehört oder verfälscht werden können. TLS bietet eine sichere Verbindung zum Internet durch Kryptographie und Authentifizierung. Normalerweise wird nur die Authentizität des Servers überprüft, während der Client unbekannt bleibt. Durch die Verwendung von PKI Es ist auch möglich, Clients zu authentifizieren.

Transport Layer Security bietet die folgenden Sicherheitsvorkehrungen für die TCP/IP-Verbindungen:

  • Authentifizierung: Erlauben Sie einer Anwendung, die Identität einer anderen Anwendung zu überprüfen, mit der sie kommuniziert.
  • Datenschutz: Daten, die zwischen Anwendungen übertragen werden, können nicht missbraucht oder eingesehen werden.
  • Integrität: Anwendungen erkennen, wenn sich Daten während der Übertragung geändert haben.

Protokolle

Das TLS-Protokoll besteht aus zwei internen Schichten:

  • Bottom Layer: Record Protocol wird verwendet, um alle Daten der obersten Schicht (Anwendungsschichtdaten und TLS-Topschichtdaten) zu übertragen.
  • Top Layer: Besteht aus drei verschiedenen Unterprotokollen: Handshake Protocol, Change Cipher Protocol und Alert Protocol. Sie sorgen für den Aufbau und die Verwaltung sicherer Verbindungen zwischen Client/Server-Anwendungen.

TLS-Protokollstapel.jpg

TLS-Protokoll

Das TLS-Protokoll verwendet Zertifikate, um die ausgetauschten Daten zu authentifizieren und den Datenschutz zu gewährleisten. Jedes Zertifikat enthält a Öffentlicher Schlüssel. Der Inhaber des Zertifikats besitzt a Privat Schlüssel mit dem öffentlichen Schlüssel im Zertifikat verknüpft.Da die Kryptographie auf der Grundlage des öffentlichen Schlüssels relativ viel Rechenzeit benötigt, verwendet das TLS-Protokoll Sitzungsschlüssel. Sie basiert auf dem öffentlichen Schlüssel und einer Zufallszahl. Diese Zufallszahl wird in der ersten Nachricht des Protokolls ausgetauscht (Client hello und Server hello). In der Folgekommunikation wird das Derivat Sitzungsschlüssel verwendet, was weniger Rechenzeit in Anspruch nimmt.

Client-Server-Handshake.jpg

TLS-Aufzeichnungsprotokoll

Record Protocol ist für die Fragmentierung und Gruppierung von Daten verantwortlich, die von den oberen Schichten gesendet werden. Die Daten werden zunächst fragmentiert (bis einschließlich TLS-Version 1.2 gibt es auch die Möglichkeit der Komprimierung, die aber Sicherheitsrisiken birgt und daher besser nicht verwendet werden sollte). Danach a Nachrichtenauthentifizierungscode (MAC) hinzugefügt werden. Endlich ein weiteres TLS Datensatz-Header platziert, um die Daten zu empfangen und zu erkennen.

TLS-Handshake-Protokoll

Handshake Protocol ermöglicht es, vertrauliche Informationen zwischen Client/Server-Anwendungen so zu übertragen, dass sie im Falle eines Abfangens durch Dritte nicht lesbar sind.

TLS-Verschlüsselungsprotokoll ändern

Change Cipher Protocol ist ein sehr einfaches Protokoll. Es wird verwendet, um Unterbrechungen beim Aufbau der TLS-Sitzung zu verhindern.

TLS-Warnprotokoll

Alert Protocol sendet Alarm bei Verbindungen zwischen Client/Server-Anwendungen. Es gibt zwei Stufen: Warnung und tödlich. Bei einem fatalen Alarm wird die Verbindung unterbrochen.

Normen

  • SSL 3.0, im Nachhinein beschrieben in RFC 6101: "Das Secure Sockets Layer (SSL) Protokoll Version 3.0"[18]
  • TLS 1.0 wird beschrieben in RFC 2246: "Das TLS-Protokoll Version 1.0"[19]
  • TLS 1.1 wird beschrieben in RFC 4346: "Das Transport Layer Security (TLS) Protokoll Version 1.1"[20]
  • TLS 1.2 wird beschrieben in RFC 5246: "Das Transport Layer Security (TLS) Protokoll Version 1.2"[21]
  • TLS 1.3 wird beschrieben in RFC 8446: "Das Transport Layer Security (TLS) Protokoll Version 1.3"[17]

Erweiterungen zu TLS 1.0

RFCs:

  • 2595: "Verwenden von TLS mit IMAP, POP3 und ACAP".[22]
  • 2712: "Hinzufügung von Kerberos Cipher Suites to Transport Layer Security (TLS)".[23]
  • 2817: "Upgrade auf TLS innerhalb von HTTP/1.1".[24]
  • 2818: "HTTP über TLS".[25]
  • 3207: "SMTP-Diensterweiterung für sicheres SMTP über Transport Layer Security".[26]
  • 3268: "fortgeschrittener Verschlüsselungsstandard (AES) Cipher Suites für Transport Layer Security (TLS)".[27]
  • 3546: "Transport Layer Security (TLS) Extensions" (veraltet von RFC 4366).[28][29]
  • 3749: "Komprimierungsmethoden für das Transportschichtsicherheitsprotokoll".[30]
  • 3943: "Transport Layer Security (TLS) Protokollkomprimierung mit Lempel-Ziv-Stac (LZS)".[31]
  • 4132: "Hinzufügung von Kamelie Cipher Suites to Transport Layer Security (TLS)".[32]
  • 4162: "Hinzufügung von SAMEN Cipher Suites to Transport Layer Security (TLS)".[33]
  • 4217: „Sichern FTP mit TLS".[34]
  • 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)".[35]

Erweiterungen zu TLS 1.1

RFCs:

  • 4347: "Transport Layer Security Datagramm".[36]
  • 4366: "Transport Layer Security (TLS)-Erweiterungen".[29]
  • 4492: "Kryptographie mit elliptischen Kurven (ECC) Cipher Suites für Transport Layer Security (TLS)".[37]
  • 4507: "Transport Layer Security (TLS) Sitzungswiederaufnahme ohne Server-Side State".[38]
  • 4680: "TLS-Handshake-Nachricht für ergänzende Daten".[39]
  • 4681: "TLS-Benutzerzuordnungserweiterung".[40]
  • 4785: "Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)".[41]
  • 5054: "Mit der Sicheres Remote-Passwort (SRP)-Protokoll für die TLS-Authentifizierung".[42]
  • 5081: "Verwenden von OpenPGP Schlüssel für die Authentifizierung von Transport Layer Security (TLS)" (veraltet von RFC 6091).[43][44]

Erweiterungen zu TLS 1.2

RFCs:

  • 5746: "Transport Layer Security (TLS) Reegotiation Indication Extension".[45]
  • 5878: "Berechtigungserweiterungen für Transport Layer Security (TLS)".[46]
  • 6091: "Verwenden von OpenPGP-Schlüsseln für die Transport Layer Security (TLS)-Authentifizierung".[44]
  • 6176: "Verbieten von Secure Sockets Layer (SSL) Version 2.0".[47]
  • 6209: "Hinzufügung der ARIE Cipher Suites to Transport Layer Security (TLS)".[48]

Externe Links