Neuer IETF-Standard: Alten Webverkehr wenigstens verschlüsseln
Nur gutes Engineering wird in Zukunft die Vertraulichkeit im Netz verbessern, sagte Edward Snowden anlässlich der CeBIT. Die Internet Engineering Task Force steuert mit der Verschlüsselung auch „alter“ Webinhalte ein neues Stück Technik bei.
Große Betreiber von älteren Web-Seiten tun sich schwer mit der raschen Umstellung auf den verschlüsselten Transport mittels HTTPS. Die Internet Engineering Task Force (IETF) hat nun den nach wie vor auf HTTP beharrenden Anbietern mit einer neuen Spezifikation eine Brücke gebaut.
Damit sollen alte HTTP-Server einen möglichst schmerzfreien Umstieg auf TLS-verschlüsselten Verkehr schaffen. Zwar fürchten manche, die "opportunistische Verschlüsselungsvariante" werde den Umbau in Richtung HTTPS und HTTP2 aufhalten, wenn nicht gar verhindern. Doch letztlich entschied man sich bei der IETF wenigstens für den Spatzen in der Hand, denn die Technik soll nicht generell gegen Angreifer absichern, sondern lediglich eine Massenüberwachung unterbinden, die bisher leicht möglich ist, weil der Großteil der Web-Kommunikation unverschlüsselt abläuft.
Verschlüsselung
Dass sie die opportunistische Verschlüsselung sämtlichen IP-Verkehrs grundsätzlich befürwortet, belegte die IETF bereits vor gut zwei Jahren mit einem eigens dafür aufgesetzten, allerdings allgemein gehaltenen RFC. Vereinfacht gesagt, darf nun die zuvor verpflichtende Vorabauthentifizierung des Gegenübers entfallen, wichtig ist, dass überhaupt verschlüsselt wird. Ohne die sonst aufwendige Schlüsselverwaltung, so die Idee, lässt sich der weltweite Anteil des verschlüsselten IP-Verkehrs viel schneller erhöhen. Das große Ziel behält die IETF freilich weiter im Visier: Eines Tages sollen sich alle Internet-Hosts authentifizieren können und sämtlichen IP-Verkehr verschlüsseln.
Das jetzt bei der IETF neu angenommene Dokument buchstabiert diese Idee für das Webprotokoll HTTP durch und beschreibt, wie alte HTTP-Server TLS-gesicherte Verbindungen aufsetzen. Dabei teilt ein Server standardmäßig auf TCP-Port 80 anfragenden Clients mIttels einer alternativen Service-Meldung mit, dass er nicht nur über HTTP, sondern auch über HTTPS erreichbar ist (TCP-Port 443).
Meldet sich der Client dann am Port 443, kann der übrige Dialog die verschlüsselte Verbindung nutzten. Zusätzlich lassen sich praktisch leere Testanfragen an den HTTP-Server schicken, also sinngemäß fragen: Ist TLS vorhanden? Getestet hat das ganze Ende vergangenen Jahres der Anbieter Cloudflare, mit zufriedenstellendem Erfolg, laut einem Blogpost der Firma.
Nur ein erster Schritt
Die Autoren, Mark Nottingham und Martin Thomson, unterstreichen in ihrem Dokument, dass so verschlüsselte Verbindungen für Man-in-the-Middle-Attacken natürlich leichte Beute bleiben. Diese müssen sich lediglich in den ersten Dialog einschleichen und den Hinweis im Header auf die TLS-Alternative unterbinden, um den unverschlüsselten Verkehr über HTTP-Port 80 zu erzwingen.
Doch es sei eben nicht Ziel dieser Spezifikation, Man-in-the-Middle-Attacken zu unterbinden, sondern Massenüberwachung zu verhindern. Das sollte gelingen, weil die opportunistische Verschlüsselung zwar durchaus Schwächen hat, aber aktives Manipulieren erfordert und so den Aufwand erhöht. Damit werde die Massenüberwachung uninteressant, so die Hoffnung der Autoren und der IETF.
Auch wollen die Autoren ihren Vorschlang nicht als verwässerte Alternative zu HTTPS verstehen, denn erst die verhindere aktive Angriffe genauso wie das passive Mitlauschen. Gegner des Konzepts hatten indes lautstark vor einer Lebensverlängerung für HTTP gewarnt. Der Druck, zum authentifizierten und verschlüsselten HTTPS umzusteigen, lasse damit nach.
Der Weg zu HTTP2
Doch ohne die HTTP-over-TLS-Alternative bleibt den aktuellen HTTP-Anbietern auch HTTP2 praktisch verschlossen, erklärt Julian Reschke, Geschäftsführer von Greenbytes und einer der Autoren von RFC7838. Das liegt vor allem daran, dass HTTP2 wegen der obligatorischen, mindestens opportunistischen Verschlüsselung über den HTTP-Port 80 überhaupt nicht gut läuft. Viele Middle-Boxen verwerfen verschlüsselten Verkehr nämlich, wenn er über Port 80 läuft.
Reschke bezweifelt, dass das Argument von der Lebensverlängerung für unsichere HTTP-Seiten stimmt. Hätte es die Alternative schon zum Start von HTTP2 schon gegeben, könnte es stimmen. Doch mittlerweile, so sagt Reschke, habe sich HTTPS rasant verbreitet. Ob der neue RFC eine Bremse wird, bezweifelt er, zumal mittlerweile durch Initiativen wie Let's Encrypt "vernünftige Alternativen für Zertifikate Land gewinnen". Bei der IETF werde man HTTP-über-TLS jetzt einfach mal beobachten, sagt der ehemalige Bereichsleiter Sicherheit bei der IETF, Stephen Farrell. Deshalb bekommt der neue RFC zunächst nur das Label "experimentell". (dz)
