|
Lexikon auf Ihrer Homepage |
|
Lexikon als Lesezeichen hinzufügen |
| Anwendung | HTTPS | IMAPS | POP3S | SMTPS | ... |
| Transport | SSL/TLS | ||||
| TCP | |||||
| Internet | IP | ||||
| Netzzugang | Ethernet | Token Bus |
Token Ring |
FDDI | ... |
Transport Layer Security (TLS), weitläufiger bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), ist ein hybrides Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Seit Version 3.0 wird das SSL-Protokoll unter dem neuen Namen TLS weiterentwickelt und standardisiert, wobei Version 1.0 von TLS der Version 3.1 von SSL entspricht. In diesem Artikel wird die Abkürzung SSL für beide Bezeichnungen verwendet.
Inhaltsverzeichnis |
Im OSI-Modell ist SSL in Schicht 6 (der Darstellungsschicht) angeordnet. Im TCP/IP Modell ist SSL oberhalb der Transportschicht (zum Beispiel TCP) und unterhalb Anwendungsprotokollen wie HTTP oder SMTP angesiedelt. In den Spezifikationen wird dies dann zum Beispiel als „HTTP over SSL“ bezeichnet. Sollen jedoch beide Protokolle zusammengefasst betrachtet werden, wird üblicherweise ein „S“ für Secure dem Protokoll der Anwendungsschicht angehängt (zum Beispiel HTTPS). SSL arbeitet transparent, so dass es leicht eingesetzt werden kann, um Protokollen ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung zu stellen. Zudem ist es erweiterbar, um Flexibilität und Zukunftssicherheit bei den verwendeten Verschlüsselungstechniken zu gewährleisten.
Das SSL-Protokoll besteht aus zwei Schichten:
| SSL Handshake Protocol | SSL Change Cipher Spec. Protocol | SSL Alert Protocol | SSL Application Data Protocol |
|---|---|---|---|
| SSL Record Protocol | |||
Das SSL Record Protocol ist die untere der beiden Schichten und dient zur Absicherung der Verbindung. Es setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste, die einzeln oder gemeinsam genutzt werden können:
Außerdem werden zu sichernde Daten in Blöcke von maximal 65.536 (216) Byte fragmentiert und beim Empfänger wieder zusammengesetzt. Dabei schreibt der Standard vor, dass die Blockgröße 214 (16384) Byte nicht übersteigt, außer der Block ist komprimiert oder verschlüsselt - dann darf die Blockgröße um 1024 bzw. 2048 Byte größer sein. Auch können die Daten vor dem Verschlüsseln und vor dem Berechnen der kryptografischen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die kryptografischen Schlüssel mit dem SSL Handshake-Protokoll ausgehandelt.
Der Aufbau einer SSL Record Nachricht lautet wie folgt: Content Type (1 Byte: Change Cipher Spec = 20, Alert = 21, Handshake = 22, Application Data = 23) | Protokollversion Major (1 Byte) | Protokollversion Minor (1 Byte) | Länge (1 Short bzw. zwei Byte)
Das SSL Handshake Protocol baut auf dem SSL Record Protocol auf und erfüllt die folgenden Funktionen, noch bevor die ersten Bits des Anwendungsdatenstromes ausgetauscht wurden:
Der Handshake selbst kann in vier Phasen unterteilt werden:
Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht. Diese Nachricht ist 1 Byte groß und besitzt den Inhalt 1. Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte Cipher Suite wechselt.
Das Alert Protocol unterscheidet etwa zwei Dutzend verschiedene Mitteilungen. Eine davon teilt das Ende der Sitzung mit (close_notify). Andere beziehen sich zum Beispiel auf die Protokollsyntax oder die Gültigkeit der verwendeten Zertifikate. Es wird zwischen Warnungen und Fehlern unterschieden, wobei letztere die Verbindung sofort beenden.
Der Aufbau einer Fehlermeldung lautet wie folgt: AlertLevel (1 Byte: Warning = 1, Fatal = 2) | AlertDescription (1 Byte: close_notify = 0, [...], no_renegotiation = 100).
In der Spezifikation von SSL werden die folgenden schweren Fehlertypen definiert:
| unexpected_message | Unpassende Nachricht wurde empfangen |
| bad_record_mac | Ein falscher MAC wurde empfangen |
| decompression_failure | Dekomprimierungsalgorithmus empfing unkorrekte Daten |
| handshake_failure | Absender konnte keine akzeptable Menge von Sicherheitsparametern bearbeiten. |
| illegal_parameter | Ein Feld in der Handshake-Nachricht lag außerhalb des erlaubten Bereichs oder stand im Widerspruch mit anderen Feldern |
In der Spezifikation von SSL werden die folgenden Warnungen definiert:
| close_notify | Teilt Empfänger mit, dass Absender keine weiteren Nachrichten auf dieser Verbindung senden wird. Muss von jedem Partner einer Verbindung als letzte Nachricht gesendet werden. |
| no_certificate | Kann als Antwort auf eine Zertifikatanforderung gesendet werden, falls passendes Zertifikat nicht verfügbar ist. (Wurde in TLS 1.0 entfernt[1]) |
| bad_certificate | Empfangenes Zertifikat war unvollständig oder falsch. |
| unsupported_certificate | Der Typ des empfangenden Zertifikats wird nicht unterstützt. |
| certificate_revoked | Zertifikat wurde vom Unterzeichner zurückgerufen. |
| certificate_expired | Zertifikat ist abgelaufen. |
| certificate_unknown | Andere nicht genau spezifizierte Grunde sind beim Bearbeiten des Zertifikats aufgetreten, die dazu führen, dass das Zertifikat als ungültig gekennzeichnet wurde. |
In der Spezifikation von TLS 1.0 wurden folgende Warnungen ergänzt[1]:
| decryption_failed | Entschlüsselungsfehler. |
| record_overflow | |
| unknown_ca | Unbekannte oder nicht vertrauenswürdige CA. |
| access_denied | Zugriff verweigert. |
| decode_error | Decodierungsfehler. |
| decypt_error | Verschlüsselungsfehler. |
| export_restriction | |
| protocol_version | |
| insufficient_security | |
| internal_error | Interner Fehler. |
| user_canceled | |
| no_renegotiation |
Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt. Inhaltlich werden sie von TLS/SSL nicht näher interpretiert.
Aus dem pre-master-secret wird in früheren Protokollversionen mit Hilfe der Hash-Funktionen SHA-1 und MD5, in TLS 1.2 mit Hilfe einer durch eine Cipher Suite spezifizierten Pseudozufallsfunktion das Master Secret berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Die Verwendung beider Hash-Funktionen sollte sicherstellen, dass das Master Secret immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt. In TLS 1.2 wird dieser Ansatz nun durch die flexible Austauschbarkeit der Funktion ersetzt.
Der Vorteil des SSL-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des SSL-Protokolls zu implementieren. Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet.
Der Nachteil der SSL-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite rechenintensiv und deshalb langsamer ist. Die Verschlüsselung selbst nimmt je nach verwendetem Algorithmus nur noch wenig Rechenzeit in Anspruch. Die verschlüsselten Daten können von transparenten Kompressionsverfahren (etwa auf PPTP-Ebene) kaum mehr komprimiert werden. Als Alternative bietet das TLS-Protokoll ab Version 1.0 die Option, die übertragenen Daten mit zlib zu komprimieren, dies wird jedoch in der Praxis vor allem aus Gründen des erhöhten Rechenaufwands kaum eingesetzt.
SSL verschlüsselt nur die Kommunikation zwischen zwei Stationen. Es sind jedoch auch Szenarien (insbesondere in serviceorientierten Architekturen) denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird. Wenn jede dieser Stationen aber nur einen Teil der Nachricht lesen darf, reicht SSL nicht mehr aus, da jede Station alle Daten der Nachricht entschlüsseln kann. Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann.
Seit einiger Zeit nutzen immer mehr Webseitenbetreiber Extended-Validation-SSL-Zertifikate (EV-SSL-Zertifikat). In der Adresszeile des Browsers wird zusätzlich ein Feld angezeigt, in dem Zertifikats- und Domaininhaber im Wechsel mit der Zertifizierungsstelle (bspw. VeriSign oder TC TrustCenter) eingeblendet werden. Zudem wird je nach verwendetem Browser und/oder Add-on die Adresszeile (teilweise) grün eingefärbt. Internetnutzer sollen so noch schneller erkennen, ob die besuchte Webseite echt ist, und besser vor Phishingversuchen geschützt werden.
SSL ist ohne eine zertifikatsbasierte Authentifizierung problematisch, wenn ein Man-In-The-Middle-Angriff erfolgt: Ist der Man-In-The-Middle vor der Übergabe des Schlüssels aktiv, kann er mit beiden Seiten den Schlüssel tauschen und so den gesamten Datenverkehr im Klartext mitschneiden. Allerdings wird seit Anfang 2010 die Sicherheit von SSL im Zusammenhang von HTTPS mit Hinweis gerade auf die möglicherweise mangelnde Vertrauenswürdigkeit der zertifizierenden Stellen (CAs) angezweifelt.[5][6][7][8]
In Verbindung mit einem virtuellen Server, zum Beispiel mit HTTP (etwa beim Apache HTTP Server über den VHost-Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro Kombination aus IP-Adresse und Port nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des SSL-/TLS-Handshakes noch nicht übertragen wurden. Dieses Problem wurde in der TLS-Version 1.2 mit der Server Name Indication behoben. Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet.
Weitere bekannte Anwendungsfälle für SSL sind POP3, SMTP, NNTP, SIP, IMAP, XMPP, IRC, LDAP, MBS/IP, FTP, EAP-TLS, TN3270 und OpenVPN.
Bekannte Implementierungen des Protokolls sind OpenSSL und GnuTLS.
