HTTP/HTTPS: Was es ist, Datenübertragungsprotokolle und TLS-Verschlüsselung

Was sind HTTP und HTTPS?

HTTP (HyperText Transfer Protocol) ist ein Anwendungsschichtprotokoll des OSI-Modells, das für die Übertragung von Hypertext-Dokumenten und anderen Daten im World Wide Web entwickelt wurde. HTTP wurde 1989 von Tim Berners-Lee entwickelt und hat mehrere Versionen durchlaufen: von HTTP/0.9 (nur GET-Anfragen und HTML-Antworten) bis zu den modernen HTTP/2 und HTTP/3. Das Protokoll arbeitet nach dem Anfrage-Antwort-Modell: Der Client sendet eine Anfrage an den Server, der Server verarbeitet sie und gibt eine Antwort zurück.

HTTPS (HTTP Secure) ist eine Erweiterung des HTTP-Protokolls, die eine Verschlüsselungsschicht durch TLS (Transport Layer Security) hinzufügt. HTTPS ist kein separates Protokoll — es ist eine Kombination aus HTTP und TLS. Über HTTPS übertragene Daten werden auf der Client-Seite verschlüsselt und auf dem Server entschlüsselt, wodurch sie für Abfangen und Manipulation unzugänglich werden. HTTPS bietet auch eine Serverauthentifizierung durch SSL/TLS-Zertifikate und stellt sicher, dass der Client eine Verbindung zum echten Server und nicht zu einem Angreifer herstellt.

Der Hauptunterschied zwischen HTTP und HTTPS ist die Sicherheit. HTTP überträgt Daten im Klartext: Jeder Netzwerkknoten zwischen Client und Server kann den Inhalt einer Anfrage oder Antwort lesen. HTTPS verschlüsselt den gesamten Inhalt, einschließlich URL, Header und Anforderungstext, und lässt nur die IP-Adresse des Servers und den Verbindungsport sichtbar. Für mobile Anwendungen, die über öffentliche Wi-Fi-Netzwerke arbeiten, ist HTTPS eine zwingende Sicherheitsanforderung.

Wie HTTP funktioniert

HTTP ist ein zustandsloses Protokoll (stateless), das über TCP/IP arbeitet. Der Client stellt eine TCP-Verbindung zum Server her (normalerweise auf Port 80 für HTTP oder 443 für HTTPS), sendet eine HTTP-Anfrage, empfängt eine HTTP-Antwort und schließt die Verbindung (in HTTP/1.1 kann die Verbindung wiederverwendet werden). Jede Interaktion zwischen Client und Server besteht aus einer Anfrage und einer Antwort. Die Zustandslosigkeit bedeutet, dass der Server keine Informationen über vorherige Client-Anfragen speichert — jede Anfrage wird unabhängig verarbeitet.

Der HTTP-Interaktionsprozess umfasst die folgenden Schritte:

• DNS-Auflösung — der Browser oder Client löst den Domainnamen über DNS in eine IP-Adresse auf
• TCP-Handshake — eine TCP-Verbindung wird durch einen Drei-Wege-Handshake hergestellt (SYN, SYN-ACK, ACK)
• TLS-Handshake — für HTTPS wird zusätzlich eine verschlüsselte Verbindung hergestellt (Zertifikats- und Schlüsselaustausch)
• HTTP-Anfrage — der Client sendet Methode, URL, Header und optional den Anforderungstext
• HTTP-Antwort — der Server gibt Statuscode, Header und Antworttext zurück

Ein wichtiges Merkmal von HTTP ist die Idempotenz von Methoden. GET, HEAD, PUT, DELETE und OPTIONS sind idempotent: Die wiederholte Ausführung derselben Anfrage ändert den Serverzustand nach der ersten Ausführung nicht. POST, PATCH und CONNECT sind nicht idempotent — jeder Aufruf kann eine neue Ressource erstellen oder den Zustand ändern. Für die mobile Entwicklung ist das Verständnis der Idempotenz entscheidend: Beim erneuten Senden einer Anfrage aufgrund eines Netzwerkfehlers muss der Client wissen, ob es sicher ist, die Anfrage zu wiederholen.

HTTPS und TLS-Verschlüsselung

HTTPS verwendet das kryptografische Protokoll TLS (Transport Layer Security) zum Schutz übertragener Daten. TLS ist der Nachfolger von SSL (Secure Sockets Layer), das 1995 von Netscape entwickelt wurde. Die Versionen SSL 2.0 und 3.0 gelten als veraltet und unsicher; die modernen Versionen TLS 1.2 (veröffentlicht 2008) und TLS 1.3 (veröffentlicht 2018) werden überall eingesetzt. TLS 1.3 reduziert insbesondere die Verbindungsaufbauzeit von 2 Round-Trips auf 1, was das Laden auf mobilen Geräten erheblich beschleunigt.

Der TLS-Handshake-Prozess umfasst die folgenden Phasen:

• Client Hello — der Client sendet eine Liste unterstützter TLS-Versionen und Cipher-Suites
• Server Hello — der Server wählt die TLS-Version und Cipher-Suite aus, sendet sein SSL/TLS-Zertifikat
• Zertifikatsprüfung — der Client überprüft das Serverzertifikat über eine Vertrauenskette bis zur Root-CA
• Schlüsselaustausch — Client und Server generieren einen gemeinsamen geheimen Schlüssel (Sitzungsschlüssel)
• Cipher Switch — beide Seiten bestätigen die Umstellung auf verschlüsselte Kommunikation

Die Überprüfung des SSL/TLS-Zertifikats ist ein kritischer Sicherheitsschritt. Der Client prüft, ob das Zertifikat: nicht abgelaufen ist, von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert wurde, mit der Domain in der URL übereinstimmt und nicht widerrufen wurde (via CRL oder OCSP). In mobilen Anwendungen wird die Verwendung von Certificate Pinning empfohlen — die Bindung an ein bestimmtes Serverzertifikat oder einen öffentlichen Schlüssel. Dies verhindert MITM-Angriffe selbst im Falle einer Kompromittierung der CA. Pinning erfordert jedoch Vorsicht: Wenn sich das Zertifikat ändert, muss die Anwendung vorab aktualisiert werden.

Struktur von HTTP-Anfrage und -Antwort

Eine HTTP-Anfrage besteht aus drei Teilen: der Anfragezeile, Headern und einem optionalen Textkörper. Die Anfragezeile enthält die HTTP-Methode, die Anforderungs-URL und die HTTP-Version. Header übermitteln Metainformationen: Inhaltstyp, Authentifizierungstoken, Cache-Einstellungen. Der Textkörper ist nur bei Methoden vorhanden, die Daten übertragen (POST, PUT, PATCH), und fehlt bei GET und DELETE.

Beispiel einer HTTP-Anfrage an eine REST-API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Anna",
    "email": "anna@example.com"
}

Eine HTTP-Antwort hat eine ähnliche Struktur: eine Statuszeile mit HTTP-Version und Statuscode, Header und Textkörper. Der Statuscode ist eine dreistellige Zahl, die das Ergebnis der Anfrageverarbeitung bestimmt. Antwortheader umfassen Content-Type, Content-Length, Cache-Control, Set-Cookie und andere. Der Antworttext enthält die angeforderten Daten im in Content-Type angegebenen Format (üblicherweise JSON für APIs, HTML für Webseiten, Bilder für Medieninhalte).

Header spielen eine entscheidende Rolle im HTTP-Betrieb. Content-Type und Accept steuern das Datenformat. Authorization übermittelt Zugriffstoken. Cache-Control verwaltet das Caching. CORS-Header (Access-Control-Allow-Origin) steuern den Zugriff von anderen Domains in Browsern. User-Agent identifiziert die Client-Anwendung. Für mobile Anwendungen sind Cache-Steuerungs-Header besonders wichtig — sie reduzieren die Menge der übertragenen Daten und verbessern die Leistung bei schwachem Signal.

HTTP-Statuscodes

HTTP-Statuscodes werden in fünf Klassen gruppiert, die durch die erste Ziffer angezeigt werden: 1xx (informativ), 2xx (Erfolg), 3xx (Weiterleitung), 4xx (Client-Fehler), 5xx (Server-Fehler). Das Verständnis dieser Codes ist für die korrekte Verarbeitung von Antworten in einer mobilen Anwendung erforderlich: 2xx bedeutet Erfolg und Daten können angezeigt werden, 4xx weist auf ein Problem mit der Anfrage hin (Fehler dem Benutzer anzeigen), 5xx weist auf ein Serverproblem hin (Anfrage später wiederholen).

Für mobile Anwendungen ist die Behandlung des Codes 401 Unauthorized besonders wichtig. Beim Erhalt dieses Codes sollte der Client versuchen, das Zugriffstoken über ein Refresh-Token zu erneuern und die ursprüngliche Anfrage zu wiederholen. Wenn die Token-Aktualisierung ebenfalls 401 zurückgibt, muss der Benutzer zum Anmeldebildschirm weitergeleitet werden. Diese Logik wird normalerweise in einem Interceptor (OkHttp) oder in der Middleware-Schicht des Netzwerk-Clients implementiert.

HTTP/1.1, HTTP/2 und HTTP/3

HTTP/1.1, veröffentlicht 1999, ist immer noch eine weit verbreitete Version des Protokolls. Sein Hauptnachteil ist Head-of-Line-Blocking: Anfragen an denselben Server werden nacheinander ausgeführt, jede wartet auf den Abschluss der vorherigen. Um diese Einschränkung zu umgehen, öffnen Browser 6–8 parallele TCP-Verbindungen zur selben Domain, was die Serverlast und den Speicherverbrauch erhöht. HTTP/1.1 überträgt Header auch im Klartext und unterstützt keinen Server Push.

HTTP/2 (2015) löst das Blockierungsproblem durch Multiplexing — mehrere Datenströme werden gleichzeitig über eine einzige TCP-Verbindung übertragen. Der Server kann Ressourcen an den Client senden, bevor der Client sie anfordert (Server Push). HTTP/2 komprimiert Header auch über HPACK, was die Menge der übertragenen Daten reduziert. Für mobile Anwendungen ist HTTP/2 besonders nützlich: Eine Verbindung ersetzt mehrere, wodurch TLS-Handshake-Zeit und Batterieverbrauch reduziert werden.

HTTP/3 (2022) ist die neueste Version des Protokolls, die QUIC (Quick UDP Internet Connections) anstelle von TCP verwendet. QUIC arbeitet über UDP und beseitigt das Head-of-Line-Blocking-Problem auf der Transportprotokollebene. HTTP/3 reduziert die Verbindungsaufbauzeit im besten Fall auf 0 Round-Trips (bei wiederholten Verbindungen) und auf 1 Round-Trip bei der ersten Verbindung, was deutlich schneller ist als HTTP/2 mit seinen 2–3 Round-Trips. Für mobile Geräte ist HTTP/3 besonders effektiv beim Wechsel zwischen Wi-Fi und mobilen Netzwerken — die Verbindung wird nicht unterbrochen, da QUIC einen Verbindungsbezeichner anstelle einer IP-Adresse verwendet.

HTTPS in der mobilen Entwicklung

Die Verwendung von HTTPS in mobilen Anwendungen ist keine Empfehlung, sondern eine zwingende Anforderung. Ab Android 9 (API 28) und iOS 9 (ATS — App Transport Security) müssen alle Netzwerkanfragen standardmäßig HTTPS verwenden. HTTP-Anfragen werden vom System blockiert, und ihre Zulassung erfordert eine explizite Ausnahme in der Anwendungskonfiguration. Google Play Store und App Store lehnen Anwendungen ab, die vertrauliche Daten über HTTP übertragen, einschließlich Passwörter, Token und personenbezogener Daten.

Die HTTPS-Konfiguration in einer Android-Anwendung umfasst:

<!-- AndroidManifest.xml — Berechtigung für Netzwerkanfragen -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — HTTPS-Konfiguration -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Unter iOS erfolgt eine ähnliche Konfiguration über Info.plist mit dem Schlüssel NSAppTransportSecurity. Zum Debuggen von HTTPS-Datenverkehr in mobilen Anwendungen werden Proxy-Tools verwendet: Charles Proxy, Proxyman oder mitmproxy. Sie erfordern die Installation eines vertrauenswürdigen SSL-Zertifikats auf dem Gerät. In Produktions-Builds müssen Debugging-Funktionen deaktiviert werden, und es muss überprüft werden, dass Certificate Pinning korrekt konfiguriert ist. Die Verwendung von OkHttp auf Android mit seinem CertificatePinner oder TrustManager auf iOS mit SecTrustEvaluate sind Standardansätze zur Implementierung von Pinning.

Ein wichtiger Sicherheitsaspekt von HTTPS in der mobilen Entwicklung ist SSL Pinning. Ohne Pinning vertraut die Anwendung jedem von einer bekannten CA signierten Zertifikat. Wenn die CA kompromittiert wird, könnte ein Angreifer den Datenverkehr der Anwendung abfangen. Pinning bindet die Anwendung an ein bestimmtes Serverzertifikat oder einen öffentlichen Schlüssel. Wenn sich das Serverzertifikat ändert, muss ein Anwendungsupdate veröffentlicht werden, daher wird Pinning mit Spielraum geplant — Bindung an ein übergeordnetes CA-Zertifikat oder Verwendung mehrerer Backup-Schlüssel.