SSL/TLS — was es ist, Protokolle und Funktionsprinzip der Verschlüsselung

Was ist SSL/TLS?

SSL (Secure Sockets Layer) ist ein Protokoll, das 1995 von Netscape zum Schutz des Webverkehrs entwickelt wurde. Die erste Version SSL 1.0 wurde nie veröffentlicht; SSL 2.0 (1995) und SSL 3.0 (1996) wurden bis Anfang der 2000er Jahre verwendet, enthielten jedoch kritische Sicherheitslücken. SSL wurde von TLS (Transport Layer Security) abgelöst — einer verbesserten, von der IETF standardisierten Version. TLS 1.0 (1999) basierte auf SSL 3.0, während die folgenden Versionen TLS 1.1 (2006), TLS 1.2 (2008) und TLS 1.3 (2018) sich allmählich von der ursprünglichen Architektur entfernten, neue Verschlüsselungsalgorithmen hinzufügten und Schwachstellen behoben. Heute gilt SSL als veraltet, und alle modernen Systeme verwenden TLS, obwohl beide Protokolle aus Gewohnheit oft zusammen als SSL/TLS bezeichnet werden.

Geschichte des Protokolls

Die Geschichte von SSL/TLS begann mit dem Bedarf an sicherer Datenübertragung im frühen Web. 1994 entwickelte Netscape SSL 1.0 für seinen Browser Navigator, aber das Protokoll wurde aufgrund schwerwiegender Sicherheitsprobleme nie veröffentlicht. SSL 2.0 wurde 1995 veröffentlicht und praktisch eingesetzt, enthielt jedoch zahlreiche Sicherheitslücken: fehlender Schutz vor Man-in-the-Middle-Angriffen, schwache Verschlüsselungsalgorithmen und Anfälligkeit für Truncation-Angriffe. SSL 3.0 (1996) behob die meisten Probleme, aber 2014 wurde die POODLE-Sicherheitslücke entdeckt, woraufhin die IETF alle SSL-Versionen offiziell für veraltet erklärte. TLS 1.0–1.3 verbesserten sukzessive die kryptografische Stärke, Leistung und Privatsphäre, wobei TLS 1.3 den Handshake von zwei auf einen Round-Trip reduzierte — entscheidend für mobile Anwendungen mit instabilen Verbindungen.

Wie funktioniert der SSL/TLS-Handshake

Handshake ist der Prozess des Aufbaus einer sicheren Verbindung zwischen einem Client und einem Server. Er besteht aus mehreren aufeinanderfolgenden Schritten, in denen die Parteien die Protokollversion aushandeln, Verschlüsselungsalgorithmen auswählen, Schlüssel austauschen und sich gegenseitig authentifizieren. In TLS 1.3 dauert der Handshake nur einen Netzwerk-Round-Trip (1-RTT), während TLS 1.2 zwei (2-RTT) benötigte.

Der erste Schritt ist das Senden eines ClientHello durch den Client — eine Nachricht mit einer Liste unterstützter TLS-Versionen, Cipher Suites und einer Zufallszahl. Der Server antwortet mit einem ServerHello, das die gewählte Version und Chiffre, sein X.509-Zertifikat und eine digitale Signatur enthält. Der Client überprüft das Zertifikat über die Kette der Zertifizierungsstellen (CA), generiert einen Sitzungsschlüssel und sendet ihn, verschlüsselt mit dem öffentlichen Schlüssel des Servers aus dem Zertifikat. Nach Bestätigung durch den Server beginnt die sichere Datenübertragung. Der gesamte Handshake dauert auf modernen Geräten 1–3 Millisekunden und ist für den Benutzer nicht wahrnehmbar.

X.509-Zertifikate und Vertrauenskette

Die Grundlage der TLS-Authentifizierung ist die Public-Key-Infrastruktur (PKI), die auf Zertifikaten im X.509-Format aufbaut. Jedes Zertifikat enthält: einen Domainnamen (Common Name oder Subject Alternative Name), den öffentlichen Schlüssel des Servers, den Namen des Ausstellers (Zertifizierungsstelle), ein Ablaufdatum und die digitale Signatur der CA. Der Client überprüft das Serverzertifikat entlang der Vertrauenskette: vom Serverzertifikat bis zur Root-CA, deren Zertifikat im Betriebssystem eingebettet ist. Auf Android-Geräten werden Root-Zertifikate im System-KeyStore gespeichert, der über Google Play Services aktualisiert wird; auf iOS — über iOS-Updates. Wenn ein Glied der Kette unterbrochen ist (abgelaufenes Zertifikat, Domain-Konflikt, unbekannte CA), bricht der Client die Verbindung ab. Für selbstsignierte Zertifikate (in der Entwicklung verwendet) ist explizites Vertrauen erforderlich — auf Android über die Network Security Config, auf iOS über NSExceptionDomains in Info.plist. Der Validierungsprozess der Zertifikatskette umfasst auch die Überprüfung des Widerrufstatus über CRL (Certificate Revocation List) oder OCSP (Online Certificate Status Protocol), obwohl auf mobilen Geräten OCSP-Anfragen oft übersprungen werden, um die Verbindung zu beschleunigen — dies ist ein Kompromiss zwischen Sicherheit und Leistung, den Architekten berücksichtigen sollten.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()