Hypertext Transfer Protocol Secure

Grundidee und Nutzen

HTTPS (Hypertext Transfer Protocol Secure) ist ein Netzwerkprotokoll für die abhörsichere Übertragung von Daten im World Wide Web. Es schützt die Kommunikation zwischen Webbrowser beziehungsweise Client und Webserver durch Transportverschlüsselung. Technisch liegt dafür TLS als zusätzliche Sicherheitsschicht zwischen HTTP und TCP. HTTPS-Adressen beginnen mit dem URI-Schema „https“; der Standard-Port ist 443/TCP.

HTTPS soll vor allem Vertraulichkeit, Integrität und Authentizität gewährleisten. Vertraulichkeit bedeutet, dass übertragene Inhalte nicht als Klartext mitgelesen werden können. Integrität bedeutet, dass Veränderungen der Daten während der Übertragung erkennbar sind. Durch Authentifizierung prüfen die Kommunikationspartner die Identität der Gegenseite. Dies soll insbesondere Man-in-the-Middle-Angriffe, bei denen sich ein Angreifer zwischen Client und Server schaltet, und teilweise auch Phishing verhindern.

Der Schutz ist besonders in offenen, unverschlüsselten WLANs wichtig: Auch wenn das Netzwerk selbst keinen Schutz bietet, bleiben HTTPS-Inhalte verschlüsselt. Browser kennzeichnen eine HTTPS-Verbindung gewöhnlich durch ein Schloss-Symbol in der Adresszeile. Die maßgeblichen Spezifikationen sind RFC 2818 „HTTP Over TLS“ aus dem Jahr 2000 und dessen 2022 veröffentlichter Nachfolger RFC 9110 „HTTP Semantics“.

Verbindungsaufbau und Nutzung

Beim Aufbau einer HTTPS-Verbindung identifizieren und authentifizieren sich die Kommunikationspartner zunächst durch den TLS- beziehungsweise früher SSL-Handshake. Anschließend vereinbaren sie mithilfe asymmetrischer Verschlüsselung oder des Diffie-Hellman-Schlüsselaustauschs einen gemeinsamen symmetrischen Sitzungsschlüssel. Asymmetrische Verfahren verwenden unterschiedliche Schlüssel zum Ver- und Entschlüsseln; bei der anschließenden symmetrischen Verschlüsselung wird derselbe Sitzungsschlüssel für die Nutzdaten verwendet. Diese Kombination ermöglicht einen geschützten Schlüsselaustausch und eine effiziente laufende Datenübertragung.

Neben Serverzertifikaten sind signierte Client-Zertifikate nach X.509.3 möglich. Mit ihnen kann der Server auch den Client authentifizieren; in der Praxis wird dies jedoch selten eingesetzt. Eine ältere HTTPS-Variante war S-HTTP.

HTTPS kann auf unterschiedliche Weise angewählt werden. Heute entspricht es dem Stand der Technik, ausschließlich HTTPS zuzulassen und HTTP-Aufrufe automatisch weiterzuleiten. Früher wurde teilweise nur der Login verschlüsselt, während weitere Seiten im Klartext übertragen wurden. Dabei konnten Cookies und Sitzungen jedoch weiterhin gefährdet sein.

HTTP Strict Transport Security (HSTS) lässt einen Server mitteilen, dass ein Browser künftig ausschließlich HTTPS verwenden soll. Der Browser speichert diese Vorgabe. Das entspricht grundsätzlich dem Sicherheitsmodell „Trust on First Use“, weil der erste Aufruf geschützt sein muss. Vorinstallierte HSTS-Listen können HTTPS bereits beim ersten Besuch erzwingen. Nutzer können HTTPS außerdem direkt eingeben oder ein Plug-in wie „HTTPS Everywhere“ verwenden. Firefox kann seit Version 83 aus dem Jahr 2020 auf ausschließliche HTTPS-Nutzung eingestellt werden; eine reine HTTP-Seite wird dann erst nach ausdrücklicher Zustimmung geöffnet.

Zertifikate und Vertrauensmodell

Die Authentizität eines HTTPS-Servers wird durch ein digitales Zertifikat innerhalb einer Public-Key-Infrastruktur (PKI) nach dem X.509-Standard bestätigt. Eine Zertifizierungsstelle, kurz CA, stellt das Zertifikat aus und ordnet es dem Server und der Domain zu. Ihr Wurzelzertifikat muss dem Browser als Vertrauensanker bekannt sein. Browser bringen dafür eigene Listen vertrauenswürdiger Stammzertifikate mit oder verwenden den Zertifikatsspeicher des Betriebssystems. Diese Listen werden durch Softwareaktualisierungen gepflegt.

Ist die ausstellende CA nicht bekannt, zeigt der Browser eine Sicherheitswarnung. Abhängig von Browser, Server und HSTS-Einstellung kann der Zugriff vollständig gesperrt sein oder eine manuelle Ausnahme erlauben. Die Regeln für die Aufnahme von CAs werden vom CA/Browser Forum bestimmt; unter anderem ist ein externer Audit zur Einhaltung der Sicherheitsvorgaben nötig. CAcert stellt kostenlose Zertifikate aus, wird aber nicht automatisch von den Browsern anerkannt. Sein Wurzelzertifikat muss daher manuell installiert werden. Die Ende 2015 gestartete gemeinnützige Zertifizierungsstelle Let’s Encrypt gibt ebenfalls kostenlose Zertifikate aus, die gängige Browser als vertrauenswürdig akzeptieren; Server-Software übernimmt Installation und regelmäßige Erneuerung.

Ein Serverbetreiber kann ein selbst-signiertes Zertifikat ohne CA erstellen. Da kein Dritter die Identität bestätigt, muss der Nutzer es manuell akzeptieren. Wird es vorab auf sicherem Weg übermittelt und in den Client importiert, kann die Authentizität auf diesem anderen Weg abgesichert werden.

Extended-Validation-Zertifikate, kurz EV-SSL, beruhen auf Richtlinien des 2007 gegründeten CA/Browser Forums. Version 1.0 erschien im Juni 2007, Version 1.1 im April 2008. Für diese Zertifikate werden zusätzlich die Postadresse und bei Firmen zeichnungsberechtigte Personen geprüft; dadurch entstehen deutlich höhere Kosten.

Ungültige oder unsicher gewordene Zertifikate sollen über Zertifikatsperrlisten (Certificate Revocation Lists, CRL) zurückgewiesen werden. Weitere Prüfverfahren sind OCSP (Online Certificate Status Protocol) und ergänzend SCVP (Server-based Certificate Validation Protocol).

Serverbetrieb, Einbindung und Umstellung

Ein HTTPS-Webserver benötigt eine TLS- beziehungsweise SSL-Bibliothek wie OpenSSL und stellt den Dienst gewöhnlich auf Port 443 bereit. Lange war für jeden Hostnamen eine eigene IP-Adresse nötig: Der Server musste das passende Zertifikat bereits während des TLS-Handshakes liefern, während der Hostname bei gewöhnlichem HTTP erst später im HTTP-Header übertragen wurde. Übergangslösungen waren „shared SSL“ mit Wildcard-Zertifikaten für zahlreiche Subdomains und SSL-Proxys.

Server Name Indication (SNI) löst dieses Problem, indem der Browser den gewünschten Hostnamen schon im TLS-Handshake übermittelt. Dadurch können mehrere HTTPS-Domains dieselbe IP-Adresse verwenden. SNI basiert laut Artikel auf TLS 1.2 und wird seit 2006 von Servern und Browsern unterstützt.

Eine Website kann HTTP-Aufrufe auf HTTPS weiterleiten oder unverschlüsselte Zugriffe ausdrücklich ablehnen. Bei Apache kann beispielsweise SSLRequireSSL verwendet werden; ein HTTP-Aufruf erzeugt dann den Fehlercode „403 – Forbidden“. Daneben können Links oder Skripte Nutzer gezielt zu HTTPS führen. In PHP lässt sich etwa mit $_SERVER['HTTPS']=='on' prüfen, ob ein Skript über HTTPS aufgerufen wurde.

Die vollständige Umstellung einer großen Website betrifft mehr als die sichtbaren Seiten. Auch Loadbalancer, Proxys, Zertifikate für mögliche Subdomains, hart codierte HTTP-Adressen und von Nutzern eingereichter Code müssen angepasst werden. Laufende Sitzungen sollen bei einem 24/7-Betrieb erhalten bleiben; außerdem sind Qualitätsprüfungen nötig.

Besonders wichtig ist die Vermeidung gemischter Inhalte („Mixed Content“), also unverschlüsselter Bilder, Stylesheets oder anderer Ressourcen innerhalb einer HTTPS-Seite. Browser können davor warnen oder die Ressourcen blockieren. Moderne Browser blockieren unverschlüsseltes Nachladen standardmäßig, weil ein Angreifer darüber Schadcode in eine ansonsten verschlüsselte Seite einschleusen könnte.

Leistung und praktische Grenzen

Client und Server handeln im TLS-Handshake einen Verschlüsselungsalgorithmus aus. Dabei besteht ein Zielkonflikt zwischen Sicherheit und Rechenleistung, besonders auf Servern mit vielen gleichzeitigen Clients. Die früher schnellen Verfahren DES und RC4 gelten nicht mehr als ausreichend sicher; RC4 wird seit 2016 von den großen Browsern nicht mehr unterstützt.

Server können Verschlüsselung durch spezielle PCI-Steckkarten, eigenständige Geräte oder programmierbare Recheneinheiten beschleunigen. Als Beispiel nennt der Artikel die MAU (Modular Arithmetic Unit) von Sun. Moderne Prozessoren bieten mit AES-NI eine Hardwarebeschleunigung für AES, das einen Teil der HTTPS-Berechnungen ausmacht. Solche Speziallösungen konkurrieren mit der fortlaufenden Leistungssteigerung von Multiprozessor- und Multi-Core-Systemen von Intel und AMD.

Der praktische Mehraufwand wurde im Laufe der Zeit deutlich kleiner. Bei Gmail verursachte Verschlüsselung 2010 weniger als 1 % der Prozessorlast, weniger als 10 KB Arbeitsspeicher pro Verbindung und weniger als 2 % des Netzwerk-Datenverkehrs. Zehn Jahre zuvor hatte der Rechenaufwand die Server noch stark belastet.

HTTPS allein beweist außerdem nicht, dass die Inhalte einer Website vertrauenswürdig sind. Auch Phishing-Seiten können ein gültiges Zertifikat besitzen und eine sichere Verbindung anzeigen. Der Artikel empfiehlt als damalige Gegenmaßnahme, Links in E-Mails nicht anzuklicken und Banking-Adressen manuell oder über Lesezeichen aufzurufen.

Angriffe und Schwachstellen

Bei HTTPS muss zwischen Schwächen der Verschlüsselung und Angriffen auf das Zertifikatsystem unterschieden werden. 2013 wurde im Zusammenhang mit der NSA-Affäre bekannt, dass die NSA beide Wege nutzte, um Zugang zu verschlüsselten Verbindungen zu erlangen.

Die eingesetzten kryptografischen Verfahren werden regelmäßig überprüft. Nach heutigem Kenntnisstand mathematisch sichere Algorithmen können dennoch durch fehlerhafte Implementierungen gefährdet werden. Ein bekanntes Beispiel ist die Schwachstelle Heartbleed in OpenSSL. Außerdem kann ein Angreifer versuchen, HTTPS schon vor dem Aufbau der verschlüsselten Verbindung zu verhindern. HSTS wurde 2012 speziell eingeführt, um solche Downgrade-Angriffe sowie Session Hijacking zu erschweren; ein Server aktiviert es über einen HSTS-Header, worauf der Browser unter anderem HTTP- in HTTPS-URLs umwandelt.

Beim Man-in-the-Middle-Angriff fängt ein Angreifer den Verkehr zwischen Client und Server ab und gibt sich als Zwischenstelle oder als Zielserver aus. Manche Varianten setzen Zugriff auf das Netzwerk des Opfers voraus, DNS-Spoofing jedoch nicht. Um sich glaubwürdig als Server auszugeben, benötigt der Angreifer ein passendes Zertifikat. Das kann gelingen, wenn eine Zertifizierungsstelle kompromittiert wird oder der Angreifer ein Zertifikat erhält, mit dem weitere Zertifikate ausgestellt werden können. HTTP Public Key Pinning und Certificate Transparency sollen solche Angriffe erschweren.

Gemischte Inhalte schaffen eine weitere Angriffsmöglichkeit, weil unverschlüsselt geladene Ressourcen verändert werden können. Wird dasselbe Cookie für verschlüsselte und unverschlüsselte Verbindungen verwendet, droht zudem Session Hijacking, selbst wenn die Anmeldung verschlüsselt war.

Im Dezember 2008 wurde auf dem 25. Chaos Communication Congress ein erfolgreicher Angriff auf MD5-basierte Zertifikate vorgestellt. Ein internationales Kryptologenteam erzeugte mit speziell programmierter Hardware, darunter einem Cluster aus 200 PlayStation-3-Konsolen, eine MD5-Kollision. Damit hätte ein Angreifer beliebige Zertifikate ausstellen können. Von MD5 war bereits zuvor abgeraten worden; EV-Zertifikate durften es nicht verwenden. Die meisten Browser akzeptieren seit 2011 keine MD5-Zertifikate mehr. Als Folgerung kündigten die Hersteller auch eine zeitliche Begrenzung der Unterstützung für SHA1-Zertifikate an.