SSL/TLS: Schlüsselkonzepte und Protokolle in der Entwicklung

Was ist SSL/TLS?

SSL (Secure Sockets Layer) und TLS (Transport Layer Security) sind kryptografische Protokolle, die eine sichere Datenübertragung über das Netzwerk gewährleisten. SSL, in den 1990er Jahren von Netscape entwickelt, gilt nach Version 3.0 aufgrund der Sicherheitslücken POODLE und BEAST als veraltet. TLS, sein Nachfolger, durchlief die Versionen 1.0, 1.1, 1.2 und 1.3 — nur TLS 1.2 und TLS 1.3 gelten als aktuell. Alle modernen mobilen Plattformen verlangen TLS für Netzwerkverbindungen, und App Store sowie Google Play überprüfen dies bei der Überprüfung.

Warum TLS für mobile Anwendungen

Ohne TLS wird der Datenverkehr zwischen der Anwendung und dem Server als Klartext übertragen — jeder im selben Wi-Fi-Netzwerk kann mit Wireshark oder tcpdump Logins, Passwörter, Token und persönliche Daten der Benutzer abfangen. TLS verschlüsselt alle übertragenen Daten (Transportverschlüsselung) und überprüft die Authentizität des Servers über eine Kette von X.509-Zertifikaten. Laut IETF (2018) verwendet TLS 1.3 nur moderne AEAD-Chiffren (AES-GCM, ChaCha20-Poly1305) und schließt veraltete Algorithmen wie RC4 und 3DES aus.

HTTPS und TLS

HTTPS (HTTP Secure) ist HTTP über TLS. Wenn eine mobile Anwendung eine Anfrage über https:// stellt, baut sie zunächst eine TLS-Verbindung zum Server auf und überträgt dann die HTTP-Header und den Anforderungstext über den verschlüsselten Kanal. Ohne HTTPS sollte keine ernsthafte API betrieben werden — das ist grundlegende Sicherheitshygiene. Laut OWASP (2026) gehören ungesicherte Verbindungen zu den Top-3-Schwachstellen mobiler Anwendungen.

Wie funktioniert der TLS-Handshake

TLS-Handshake ist der Prozess des Aufbaus einer sicheren Verbindung zwischen Client und Server. Die Parteien handeln die Protokollversion aus, wählen eine Cipher Suite aus, tauschen Schlüssel über asymmetrische Kryptografie aus und überprüfen Zertifikate. Bei TLS 1.2 benötigt der Handshake 2 Round Trip Time (2 RTT): Client → Server mit ClientHello, Server → Client mit ServerHello und Certificate, dann die abschließenden Finished-Nachrichten. TLS 1.3 reduziert diesen Prozess auf 1 RTT.

Detaillierte Phasen des TLS 1.2-Handshakes

Erste Phase: ClientHello — der Client sendet unterstützte TLS-Versionen, eine Liste von Cipher Suites und eine Zufallszahl. Der Server antwortet mit ServerHello, wählt eine Version und Cipher Suite aus, sendet sein X.509-Zertifikat (Certificate) und die ServerHelloDone-Nachricht. Der Client überprüft das Zertifikat über eine Kette vertrauenswürdiger Zertifizierungsstellen (CA), generiert ein Pre-Master-Secret, verschlüsselt es mit dem öffentlichen Schlüssel aus dem Zertifikat und sendet es im ClientKeyExchange an den Server. Danach generieren beide Seiten Sitzungsschlüssel und tauschen ChangeCipherSpec- und Finished-Nachrichten aus. Ab diesem Zeitpunkt werden alle Daten symmetrisch verschlüsselt.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Beispiel für die Behandlung von URLAuthenticationChallenge auf iOS über URLSessionDelegate. Diese Methode wird bei jedem TLS-Handshake aufgerufen und ermöglicht der Anwendung eine benutzerdefinierte Überprüfung des Serverzertifikats. Fügen Sie für die Produktion die Zertifikatsüberprüfung über SecTrustEvaluateWithError hinzu und vergleichen Sie mit einem vorab gespeicherten Fingerabdruck — erst dann rufen Sie useCredential auf.

TLS 1.2 vs. TLS 1.3

TLS 1.3 (RFC 8446, 2018) ist das erste große Protokoll-Update seit 10 Jahren. Die wichtigsten Verbesserungen: Handshake auf 1 RTT reduziert (0 RTT für wiederholte Verbindungen), veraltete Cipher Suites entfernt (RSA-Schlüsselaustausch, CBC-Modus), obligatorische Perfect Forward Secrecy (PFS) und Schutz vor Downgrade-Angriffen durch signed transcript. Laut Qualys SSL Labs (2026) bietet TLS 1.3 dank PFS auch bei Kompromittierung des langfristigen Serverschlüssels Schutz.

0-RTT (Zero Round Trip Time) ist eine TLS 1.3-Funktion, die es dem Client ermöglicht, bei einer wiederholten Verbindung über PSK (Pre-Shared Key) sofort Daten zusammen mit ClientHello zu senden. Dies beschleunigt das Laden nachfolgender Bildschirme in mobilen Anwendungen, insbesondere bei häufigen Anfragen an denselben Server. Allerdings sind 0-RTT-Daten nicht vor Replay-Angriffen geschützt — sie können abgefangen und erneut gesendet werden. Verwenden Sie 0-RTT nur für idempotente Anfragen (GET, PUT) ohne Nebenwirkungen.

TLS auf iOS: App Transport Security

App Transport Security (ATS) ist Apples Mechanismus, der HTTPS-Verbindungen mit TLS 1.2 oder höher erfordert und seit iOS 9 standardmäßig aktiviert ist. ATS blockiert alle HTTP-Verbindungen und HTTPS mit TLS unter 1.2. Der Entwickler kann Ausnahmen in Info.plist über NSAppTransportSecurity für bestimmte Domänen konfigurieren, aber Apple empfiehlt, Ausnahmen zu minimieren und überall HTTPS zu verwenden. Ein Verstoß gegen die ATS-Anforderungen führt zur Ablehnung der App bei der App Store-Überprüfung.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

ATS-Konfiguration in Info.plist. NSAllowsArbitraryLoads ist auf false gesetzt — alle Verbindungen müssen HTTPS verwenden. Für die Domäne cdn.example.com ist eine Mindest-TLS-Version 1.2 festgelegt, NSAllowsLocalNetworking=true erlaubt HTTP für lokale Netzwerke (nützlich für Entwicklungsserver). Apple empfiehlt dringend, NSAllowsArbitraryLoads nicht ohne NSExceptionDomains zu aktivieren — dies sollte eine Ausnahme und keine allgemeine Regel sein.

TLS auf Android: Network Security Config

Network Security Config ist der Mechanismus von Android zur Konfiguration von HTTPS und TLS ohne Änderung des Java/Kotlin-Codes. Die Konfiguration wird in der Datei network_security_config.xml angegeben und über das Attribut android:networkSecurityConfig in AndroidManifest eingebunden. Unterstützt die Konfiguration vertrauenswürdiger Zertifikate (Benutzer- und System-CA), Certificate Pinning, Deaktivierung von Klartext-HTTP, Debug-Überschreibungen und Traffic-Umleitung.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config für Android. Base-config blockiert Klartextverkehr und vertraut nur System-CA-Zertifikaten (keine Benutzerzertifikate — Schutz vor Installation von MitM-Zertifikaten durch Benutzer). Domain-config für api.example.com enthält einen Pin-Set mit einem SHA-256-Zertifikatsfingerabdruck. Wenn sich das Serverzertifikat vor dem angegebenen Ablaufdatum ändert, wird die Verbindung abgelehnt — dies ist eine strenge Form von Certificate Pinning.

Certificate Pinning und Sicherheit

Certificate Pinning ist eine Technik zur Fixierung des Zertifikats oder öffentlichen Schlüssels des Servers im Anwendungscode. Bei jedem TLS-Handshake vergleicht der Client das Serverzertifikat mit einem vorab gespeicherten Fingerabdruck (SHA-256-Hash). Selbst wenn ein Angreifer ein vertrauenswürdiges CA-Zertifikat erhält oder die Zertifizierungsstelle kompromittiert, kann er keinen MitM-Angriff durchführen — die Anwendung überprüft den spezifischen Fingerabdruck, nicht die CA-Kette. Dies ist besonders wichtig für Finanzanwendungen und Apps, die mit sensiblen Daten umgehen.

Risiken und Alternativen zu Pinning

Certificate Pinning erfordert Vorsicht: Wenn sich das Serverzertifikat ändert, werden alle älteren Versionen der Anwendung die Verbindung verlieren. Es wird empfohlen, mehrere Backup-Fingerabdrücke (primär + Backup) zu speichern, ein Ablaufdatum für den Pin-Set festzulegen und einen Fallback-Mechanismus über die Standard-CA-Überprüfung zu implementieren. Eine Alternative ist Trust On First Use (TOFU), bei dem die Anwendung das Zertifikat bei der ersten Verbindung speichert und den Benutzer bei Änderungen warnt. Laut OWASP (2026) gehört das Fehlen von Certificate Pinning zu den Top-3-Schwachstellen mobiler Anwendungen (M3: Unsichere Kommunikation).

Implementierung von Pinning in Alamofire

In Alamofire 5+ wird Certificate Pinning über ServerTrustManager mit PinnedCertificatesTrustEvaluator (vollständige Zertifikatsprüfung) oder PublicKeysTrustEvaluator (nur öffentlicher Schlüssel) konfiguriert. Der öffentliche Schlüssel ist vorzuziehen — er ändert sich bei der Erneuerung des Zertifikats mit derselben CA nicht. Erstellen Sie einen ServerTrustManager mit einem [host: evaluator]-Wörterbuch, übergeben Sie ihn an Session und verwenden Sie ihn für alle Anfragen an geschützte APIs.