Gemeinsam gegen die „Ossifizierung“ des Internets

In den 90er Jahren des letzten Jahrhunderts zerbrachen sich Softwareentwickler weltweit den Kopf darüber, was passieren würde, wenn die Jahreszahl künftig nicht mehr mit „19“ beginnt. Dieser sogenannte Millennium-Bug ist vielleicht das bekannteste Beispiel für „Ossifizierung“: die Annahme, dass etwas unveränderlich ist, nur weil es noch nie – oder schon lange keine – Veränderung gab.

Der Millennium-Bug ist ein besonders drastisches Beispiel dafür, weil diese Veränderung leicht vorhersehbar war. Derartige Risiken verbergen sich aber auch hinter den Lösungen, die wir als Provider von Internetinfrastruktur anbieten. Da wir unseren Kunden nur einen eingeschränkten Zugang zu den Internetprotokollen bieten, müssen wir gemeinsam sicherstellen, dass wir die Zukunft des Internets nicht versehentlich aufs Spiel setzen. Betrachten wir die Rolle, die uns allen dabei zukommt, doch einmal genauer:

Weiterentwicklung ist das Erfolgsrezept des Internets

Das Internet hat sich bislang als bemerkenswert robust erwiesen. Einer der Gründe, warum die in den 70er, 80er und 90er Jahren entwickelten Netzwerkprotokolle nach wie vor funktionieren, ist die Tatsache, dass ihre Weiterentwicklung von Anfang an eingeplant war. Die Entwickler haben zukünftige Veränderungen vorhergesehen und das Hinzufügen neuer Funktionen und die Abänderung bestimmter Aspekte des Protokolls ganz bewusst berücksichtigt, damit das Internet nicht daran zerbricht.

Dies ist besonders deshalb wichtig, weil es unmöglich ist, sämtliche Internetnutzer auf einmal auf den neusten Stand zu bringen. Es muss möglich sein, Änderungen schrittweise einzuführen, ohne dabei die Kommunikation zu beeinträchtigen. Das geschieht meist über Erweiterungs- und Versionierungsmechanismen, die es uns ermöglicht haben, (allmählich) IPv6 einführen, als IPv4 an seine Grenzen stieß. IPv6 ermöglicht die Einführung neuer TLS-Versionen, mit denen wir die Sicherheit des Internet und anderer Anwendungen verbessern können. Außerdem ermöglicht es uns die Nutzung von HTTP/2, wodurch wir die Performance des Internets optimieren und mithilfe von Headern, Methoden und Statuscodes neue Funktionen einführen können. 

Ossifizierung verhindert die Weiterentwicklung des Internets

Wenn Anwendungen, Netzwerkgeräte oder sonstige Komponenten des Internets die Versionierung und Erweiterbarkeit von Protokollen beschränken, führt dies zu Ossifizierung. Die „Gelenke“ der Protokolle, die für Flexibilität sorgen, „rosten“ also ein und werden unbeweglich. Das geschieht häufig, wenn Personen, die Protokolle implementieren oder nutzen, davon ausgehen, dass sich das Protokoll nie ändert. 

Würde beispielsweise eine Web Application Firewall (WAF) alle Anfragen ablehnen, deren Header-Wert eine Zeichenfolge wie target=value enthält, könnten Browser nicht mehr so leicht neue Header einführen. So unwahrscheinlich das auch scheinen mag – es ist bereits passiert.

TLS 1.3 leidet ebenfalls unter Ossifizierung. In diesem Protokoll ist festgelegt, dass die Versionszeichenfolge im Protokoll-Header auf den Wert für TLS 1.2 eingestellt ist, da einige Server keine höhere Version in Betracht ziehen wollten als diejenige, die sie selbst unterstützten. Diese „Versionsintoleranz“ sorgt bei der Bereitstellung neuer Protokolle für mehr Komplexität und erhöhte Risiken.

Ossifizierung erschwert die Einführung neuer Funktionen im Protokoll, bis das Protokoll schließlich so verknöchert ist, dass es vollständig ersetzt werden muss.Genau dies findet aktuell beim TCP statt. Viele Netzwerkgeräte (z. B. sogenannte „WAN Accelerators“) wollen der Performance von TCP-Verbindungen auf die Sprünge helfen, indem sie bestimmte Reaktionen vorwegnehmen, weshalb schließlich ein völlig neuer Ansatz (nämlich QUIC) erforderlich war. Die „nützlichen“ Komponenten erwiesen sich häufig als nachteilig für Performance und Zuverlässigkeit, da deren Entwickler nicht mit anderen Nutzern in Kontakt standen und ihre Änderungen oder Optimierungen über die Endpoints einführen wollten.

Minimierung des Ossifizierungsrisikos mit Fastly

Über VCL und Compute@Edge macht Fastly die Eigenschaften grundlegender Protokolle für unsere Kunden zugänglich. Hierbei handelt es sich um eine bewusste Entscheidung: Indem diese Informationen exponiert werden, können Sie auf der Grundlage von Fastly umso leistungsfähigere Systeme bauen. Ganz im Einklang mit unserer internen Vorgehensweise fordern wir gleichzeitig unsere Kunden dazu auf, die Zusammenhänge zu verstehen und Entscheidungen und Annahmen zu vermeiden, die zu einer versehentlichen Ossifizierung dieser Protokolle führen könnten. 

Besonders Mutmaßungen über das Client-Verhalten oder darüber, wie „normaler“ Traffic aussehen sollte, bergen ein Risiko für Ossifizierung. Selbst wenn Sie mit Ihren Vermutungen kurzfristig richtig liegen, können zukünftige Veränderungen (z. B. durch Browser) diese invalidieren, wodurch Ihre Anwendung auf unvorhersehbare Weise fehleranfällig wird.

Auf Ossifizierungsrisiken stößt man oft, wenn man Dinge wie Client Classifier und WAFs erstellt, die abhängig von der genauen Beschaffenheit des Protokolls das Verhalten einer Website verändern. Wenn Sie unsere WAF oder unsere integrierten Geräteerkennungsmechanismen (z. B. client.class.*, client.platform.* und client.display.* in VCL) nutzen, kümmern wir uns für Sie um einen Großteil der Ossifizierungsrisiken. Wenn Sie aber ähnliche Produkte selbst entwickeln, tragen Sie möglicherweise ungewollt zu einer weiteren Ossifizierung des Internets bei.

Vor allem die Zurückweisung von Anfragen aufgrund von grundlegenden Protokoll-Metadaten wie der HTTP-Version, HTTP-Anfrage-Headern und Informationen zu TLS-, TCP- und QUIC-Verbindungen, kann zu einem erhöhten Ossifizierungsrisiko führen. Ein weiterer Risikofaktor sind fehlende effektive Feedback-Kanäle. Wenn diejenigen, die von der Einschränkung betroffen sind, sich nicht zu Wort melden können und das Problem umgehen müssen, wird diese Notlösung womöglich zu einem festen Bestandteil des Internets. 

Glücklicherweise lassen sich derartige Funktionen und Produkte auch auf verantwortungsvolle Weise erstellen. Sie können selbst einen Beitrag dazu leisten:

• Testen Sie kontinuierlich eine Vielzahl neuartiger Browser und anderer HTTP-Clients, um Interoperabilitätsprobleme frühzeitig zu erkennen.

• Prüfen Sie regelmäßig Browser-Bugtracker auf Erwähnungen Ihres Produkts.

• Achten Sie darauf, dass Ihr Produkt im Protokoll leicht identifizierbar und dadurch leichter auffindbar ist.

• Sorgen Sie dafür, dass Browser- und Client-Entwickler sich bei Bedarf mit Ihnen in Verbindung setzen können, z. B. über einen Support-Kanal, einen Bugtracker oder eine dedizierte E-Mail-Adresse.

• Verfolgen Sie die Entwicklung der relevanten Protokolle, um Änderungen zu erkennen, die Ihren bisherigen Annahmen widersprechen. Ein guter erster Anlaufpunkt dafür wären die IETF HTTP Working Group und die IETF TLS Working Group. Es gibt auch eine dedizierte http-grease-Liste, um Ossifizierungsprobleme in diesem Protokoll zu besprechen und zu melden.

Um Ossifizierung zu vermeiden, müssen alle Akteure im Internet am selben Strang ziehen. Auch wenn es immer einige Websites und Programme gibt, die Protokoll-Erweiterungspunkte missbrauchen, lässt sich durch eine gemeinsame Minimierung von Ossifizierungsrisiken sicherstellen, dass sich das Internet organisch weiterentwickelt und den Herausforderungen der Zukunft gewachsen ist.