Kampf um das Internet der Zukunft
Alle Datenpakete, die über das Internet verschickt werden, sind in mehrere Schichten eingebettet. Jetzt steht eine Renovierung dieser Schichten an. Sie soll am Ende das Web wesentlich schneller und sicherer machen - aber nur, wenn die NSA mitspielt.

[img=250,right]https://darklight.to/picshare/upload/big/2013/11/29/52986ac0e740a.jpg [/img] Zufriedenheit ist ein trügerisches Gefühl – besonders im Internet. Immer mehr Surfer greifen tief in die Tasche und leisten sich einen teuren Breitbandanschluss. Anschließend bestätigen ihnen Messtools: Ja, sie haben ein Download-Tempo von 50 MBits/s und mehr. Doch schnell stellt sich Ernüchterung ein. Im Alltag bauen sich Webseiten kaum schneller auf als über den alten DSL-Anschluss. Bessere Hardware macht das Web eben nicht spürbar flotter, solange veraltete Internetprotokolle, über die Browser und Server miteinander kommunizieren, den Seitenaufruf ausbremsen.

Sie stammen noch aus einer Zeit, als das Internet simple HTML-Seiten mit ein paar Grafiken über die Leitung schickte. Die aktuelle Netzkommunikation geht weit darüber hinaus: Mehrere Hundert Zeilen Skriptcode sind auf Webseiten ebenso üblich wie das Laden von Webelementen aus den verschiedensten Quellen. Oft ist auch eine beständige Interaktion zwischen Surfer und Webserver erforderlich oder eine aktive Verschlüsselung zum Schutz der Privatsphäre.

Umstieg von HTTP 1.1 auf 2.0
Bestes Beispiel ist HTTP, das zentrale Anwendungsprotokoll, das die Kommunikation zwischen Browser und Server regelt. Die aktuelle Version 1.1 wurde schon 1999 eingeführt und zwischendurch sporadisch optimiert, doch grundlegende Schwächen bleiben bestehen. Deshalb kann das Protokoll die Möglichkeiten der verfügbaren Bandbreite nicht ausreizen. Zudem erzeugt es durch seinen großen Overhead unnötigen Datenverkehr. Kein Wunder, dass die Internet Engineering Task Force (IETF), die für die technische Weiterentwicklung des Netzes Zuständig ist, sich seit 2012 mit der Renovierung des Verbindungsprotokolls befasst.

Der Weg zu HTTP 2.0 steht schon fest: Seine Einführung haben die Spezialisten für Ende 2014 angepeilt. Im Juli wurde ein Entwurf zur Implementierung freigegeben, seit August laufen erste Tests.

[img=600]https://darklight.to/picshare/upload/big/2013/11/29/52986b84a74a3.PNG [/img]

Konkurrenz:SPDY, Speed+Mobility und HTTP 2.0
Im letzten Jahr haben Google und Microsoft jeweils eigene Vorschläge zu den technischen Neuerungen von HTTP 2.0 eingebracht. Das von Google entwickelte Protokoll SPDY konkurrierte mit Microsofts HTTP Speed+Mobility.

Beide Angebote wollten jeweils die Geschwindigkeitsprobleme von HTTP 1.1 lösen und unterschieden sich hauptsächlich in der Frage, ob HTTP 2.0 durchgehend verschlüsselt werden soll. Während sich SPDY als Grundlage für HTTP 2.0 durchgesetzt hat, verzichtet die IETF auf die in SPDY obligatorische Verschlüsselung, da sie von Mobilgeräten eine gewisse Rechenpower erfordern und damit deren Akkulaufzeit verkürzen würde. Zudem trifft der Verschlüsselungszwang die Betreiber kleiner Webseiten unnötig hart, denn das dafür notwendige Zertifikat kostet Geld.

Nur auf eine starke Verschlüsselung ist Verlass
Der Weg zu HTTP 2.0 schien damit geebnet, bis die Enthüllungen von Edward Snowden die schönen Pläne durchkreuzten. Anfang September wurde klar, dass der amerikanische Auslandsnachrichtendienst, die National Security Agency (NSA), in der Lage ist, auch per HTTPS verschlüsselten Datenverkehr im großen Stil abzuhören. Der Verschlüsselungsexperte Bruce Schneier sprach sogar davon, dass die US-Regierung das „Internet verraten“ hat. Damit geriet das bisher nachrangig behandelte Thema „Sicherheit von HTTP 2.0“ in den Focus. Der Chariman Jari Arkko hat es für die nächste IETF-Sitzung im November in Vancouver auf die Tagesordnung gesetzt. Dort steht eine grundlegende Neubewertung des Protokolls im Zusammenhang mit den Snowden-Enthüllungen an. Bis dahin sammelt die Gruppe Anregungen, wie man die Integrität der Webverschlüsselung von HTTP 2.0 garantieren kann.

Die Webverschlüsselung HTTPS nutzt die vorhandenen SSL- und TSL-Protokolle, um eine sichere Verbindung aufzubauen. Zunächst wird dazu eine asymmetrische Verschlüsselung, bestehend aus einem Public und einem Private Key, durchgeführt: Der Server schickt dem Browser einen zertifizierten Public Key. Der Browser checkt anhand der Zertifizierung, ob der Key gültig ist, verschlüsselt damit den Session Key für die symmetrische Verschlüsselung des Datenverkehrs und verschickt ihn an den Server. Der Server nutzt seinen Private Key, um aus der Nachricht den Key für die symmetrische Verschlüsselung zu extrahieren. Jetzt sind Server und Browser im Besitz desselben Session Keys und können ihre weitere Kommunikation damit verschlüsseln.

[img=650]https://darklight.to/picshare/upload/big/2013/11/29/52987301f17d1.PNG [/img]
[spoiler=NSA: Hintertür in der Webverschlüsselung]Eine Instanz wie NSA, die den gesamten Webverkehr aufzeichnet, könnte diese Kommunikation entschlüsseln, wenn sie später einmal etwa per Gerichtsbeschluss oder Hack an den Private Key des Servers herankommt.

Eine Instanz wie die NSA; die den gesamten Webverkehr aufzeichnet, könnte diese Kommunikation entschlüsseln, wen sie später einmal etwa per Gerichtsbeschluss oder Hack an den Private Key des Servers herankommt. Deshalb wurde im Rahmen von HTTP 2.0 und des ebenfalls in Entwicklung befindlichen Verschlüsselungsprotokolls TLS 1.3 der flächendeckende Einsatz einer anderen Methode für die Schlüsselgenerierung vorgeschlagen: Bei Perfect Forward Secrecy (PFS) gibt es keinen direkten Schlüsselaustausch. Stattdessen verständigen sich Server und Browser mittels mehrerer Nachrichten und einem darauf aufbauenden Kryptoverfahren auf die unabhängige Erzeugung eines gemeinsamen symmetrischen Schlüssels, der nicht über das Web versendet wird. Er funktioniert nur für eine Sitzung und wird danach gelöscht.

Für PFS müssen aber die kryptografischen Verfahren, mit denen die Keys generiert werden, sicher sein. In der Vergangenheit hat die NSA aktiv an diesen Verfahren mitgearbeitet und anscheinend Backdoors eingebaut, mit denen sie sich umgehen lassen. Bekannt geworden ist die Kompromittierung der elliptischen Kurve im Zufallsgenerator Dual_EC_DRBG: Die Werte, die auf diesen Kurven liegen, werden zur Generierung der Zufallszahlen für das asymmetrische Schlüsselpaar verwendet. Auch andere Kurven, die von der US-Standardisierungsbehörde NIST veröffentlicht wurden, stehen unter Verdacht. Mittlerweile liegt ein Vorschlag von Simon Josefsson bei der IETF vor, um eine andere elliptische Kurve mit der Bezeichnung 25519 für TLS 1.3 zu verwenden, die nicht von der NIST stammt. Damit würde TLS 1.3 die NSA-Hintertür wieder schließen.

[img=550]https://darklight.to/picshare/upload/big/2013/11/29/52986d12d0b18.PNG [/img]
Der Browser bestimmt ab jetzt wo es lang geht
Doch ein neues TLS reicht nicht aus: Im ebenfalls bei HTTPS eingesetzten Verschlüsselungsverfahren RC4 wird eine von der NSA eingebaute Schwäche vermutet. RC4 ist Teil aktiver Sicherheitsprotokolle von SSL 2.0 bis TLS 1.2 und wird in 50 Prozent des verschlüsselten Webverkehrs eingesetzt. Nun könnte man RC4 für TLS 1.3 einfach nicht mehr berücksichtigen, doch bei der jetzigen Implementierung der Sicherheitsschicht bestimmt der Server, welches Protokoll verwendet wird. Während die neuesten Browser-Versionen von Chrome und IE auch das aktuelle TLS 1.2 implementiert haben, nutzt die Mehrzahl aller Webserver hauptsächlich die veralteten Verfahren SSL 3.0 oder TLS 1.0. Beide haben bekannte Lücken, die sich ein Angreifer zunutze machen kann. Daher lautet ein Vorschlag zu HTTP 2.0, das Verhältnis umzukehren: Künftig soll der Browser bestimmen, welches Protokoll gelten soll. Letztlich könnte dann der User einstellen, wie gut eine HTTPS-Verbindung geschützt sein soll.[/spoiler]
[spoiler=SSL/TLS: Sicherheitslöcher stopfen]Aktuell wirksame TLS-Angriffe beruhen auch darauf, dass die Pakete abgefangen und/oder manipuliert weitergeschickt werden. Eine zentrale Rolle spielt dabei der Message Authentication Code (MAC), der während der Kommunikation per Session Key in jedem Paket mit übertragen wird.

Der MAC wird aus dem Hashwert des Datenpaktes und dem Session Key gebildet. Anhand des MAC ermittelt der Empfänger, ob die Datenpakete auch vom Sender stammen. Aktuell gehen alle Sicherheitsprotokolle von SSL wie TLS nach der Devise „MAC then encrypt“ vor. Damit wird der Hashwert des noch nicht verschlüsselten Paketinhalts verwendet, um den MAC zu generieren.

Encrypt then MAC
Als Gegenmaßnahme liegt ein Antrag für eine TLS-Erweiterung vor, die den umgekehrten Weg geht: Bei „Encrypt then MAC“ wird der Hashwert des verschlüsselten Paketinhalts verwendet, mit dem Angreifer wenig anfangen können. Ob all diese Maßnahmen ausreichen, um die Geheimdienste am globalen Schnüffeln zu hindern, ist allerdings noch ungewiss. Sie schließen ja nur die schon bekannten Schwächen. Zumindest steht das umstrittene Thema, ob HTTP 2.0 überhaupt stets durchgehend verschlüsselt werden soll, erneut auf der Agenda der Internet Engineering Task Force.

[img=470]https://darklight.to/picshare/upload/big/2013/11/29/52986dd03a19b.PNG [/img]
[/spoiler]
[spoiler=Leistung: Performance-Schwächen beheben]Einig ist sich die IETF über die Technologien, welche die Performance-Probleme von HTTP 1.1 beseitigen sollen. Die Grundlage dafür bildet das Google-Protokoll SPDY in der Version 3, das aktuelle Browser wie Chrome, IE; Firefox und Opera schon unterstützen – Apples Safari fehlt allerdings noch in der Liste.

SPDY geht die strukturelle Defizite von HTTP 1.1 an: So muss der Server bei HTTP 1.1 für jedes einzelne Element eine eigene TCP-Verbindung aufbauen. Er wirft deshalb gleich mehrere parallele Verbindungen an, was wiederum zu unnötigem Datenverkehr und potenziell zum Head-of-Line-Blocking führt. Beim Head-of-Line-Blocking staut sich die Abarbeitung der Datenpakete, denn die kommen immer in der Reihenfolge an, in der sie angefragt wurden, egal, ob die Anfrage fehlerhaft ist oder deren Bearbeitung zu lange dauert. Zudem geht die HTTP-Verbindung immer vom Client aus. Der Browser muss ständig nachfragen, ob sich der Inhalt der Internetseite verändert hat. Der Server sendet von sich aus keine Aktualisierungen.

[img=490]https://darklight.to/picshare/upload/big/2013/11/29/52986f1b302eb.PNG [/img]
Ist dagegen einmal eine HTTP-2.0-Verbindung aufgebaut, können Browser und Server unabhängig voneinander eigene Streams aufmachen, durch die sie ihre Datenpakete schicken. Das geschieht per Multiplexing parallel und gleichzeitig. Im Gegensatz zu HTTP 1.1 realisiert 2.0 die Parallelisierung innerhalb einer einzigen TCP-Verbindung. Das reduziert besonders die Auslastung auf Seiten des Servers erheblich, der ja viele Browser-Abfragen gleichzeitig abarbeiten muss. Die Frames werden zudem mit einer Priorisierung gekennzeichnet, sodass der Browser beziehungsweise Server die Reihenfolge bei ihrer Dekodierung dementsprechend anpassen kann. Ein Head-of-Line-Blocking gibt es nicht mehr. Zusätzlich darf der Server nun per Push Nachrichten an den Browser schicken.

Optimierte Paket-Header
Optimiert wurden auch die Paket-Header. In der Version 1.1 überträgt HTTP diese in Textform und unkomprimiert. Dadurch werden sie unnötig groß und müssen zur Verarbeitung erst einmal in Binärcode übersetzt werden. Die Version 2.0 komprimiert die Header und sendet sie gleich in Binärcode. Das verkleinert vor allem den ersten Frame des Datenpakets, der so viel schneller verarbeitet werden kann. Dadurch reduziert sich die Latenz erheblich.

[img=570]https://darklight.to/picshare/upload/big/2013/11/29/52986f7f98546.PNG [/img]
Viele Funktionen von HTTP 1.1 und TCP bedingen einander, wie das Beispiel der Parallelisierung zeigt, denn das TCP-Protokoll stellt Services bereit, die HTTP fehlen: Es sorgt dafür, dass Verluste bei der Datenübertragung entdeckt sowie behoben werden und legt auch die Reihenfolge der Pakete fest. Doch diese Kontrollfunktionen erhöhen wiederum die Größe der TCP-Header und damit die Latenz. Der Verbindungsaufbau erfolgt bei TCP zudem per dreistufigem Handshake, was die Latenz noch einmal erhöht.

HTTP 2.0 übernimmt TCP-Aufgaben
Einige Aufgaben, derer sich TCP annimmt, bremsen aber HTTP 2.0 aus, beziehungsweise HTTP 2.0 übernimmt sie jetzt. Statt der TCP-Paketreihenfolge bestimmt die Frame-Priorisierung, wie die Datenpakete verarbeitet werden. Google rät daher, das schnellere, aber auch unzuverlässige UDP als Transportprotokoll zu nehmen und leicht zu modifizieren: Google QUIC basiert auf UDP, wird aber um eine eingebaute Fehlerkorrektur erweitert. Die per QUIC mitgeschickten Korrekturblöcke machen die Fehlererkennung von TCP überflüssig. Den umständlichen Handshake kann TCP ebenfalls vernachlässigen, denn HTTP 2.0 baut ja schon einen Stream zwischen Server und Browser auf, über den beide miteinander kommunizieren. Langfristig will Google TCP nicht ersetzen, sondern QUIC in TCP integrieren. Den Umstieg kann man sich ebenso sanft vorstellen wie den von HTTP 1.1 auf 2.0. Der User wird HTTP 2.0 per Browser-Update zügig erhalten. Der Browser wird dann automatisch beim Server anfragen, ob er 2.0 unterstützt. Wenn ja, dann geht es los ins Internet der Zukunft.[/spoiler]
Quelle