Einführung von time.cloudflare.com

Cloudflare war schon immer führend bei der Bereitstellung sicherer Versionen von unsicheren Internetprotokollen für die kostenlose Nutzung durch jedermann. Im Jahr 2014 brachten wir zu unserem bestehenden kostenlosen HTTP-Tarif einen der weltweit ersten kostenlosen, sicheren HTTPS-Dienste (Universal SSL) auf den Markt. Als wir den DNS-Resolver 1.1.1.1 einführten, unterstützten wir auch die neuen, sicheren Versionen von DNS (DNS-over-HTTPS und DNS-over-TLS). Im Rahmen der Crypto Week 2019 tun wir heute das Gleiche für das Network Time Protocol (NTP), das vorherrschende Protokoll zur Zeitsynchronisation über das Internet.

Diese Ankündigung ist für mich eine persönliche Angelegenheit. Ich habe die letzten vier Jahre damit verbracht, Schwachstellen in Zeitprotokollen zu identifizieren und zu beheben. Heute bin ich stolz darauf, an der Einführung eines Dienstes beteiligt zu sein, der mir das Leben von 2015 bis 2019 schwerer gemacht hätte: time.cloudflare.com, ein kostenloser Zeit-Dienst, der sowohl NTP als auch das neu entstehende Protokoll Network Time Security (NTS) zum Schutz von NTP unterstützt. Jetzt kann jeder sicher Zeit von all unseren Rechenzentren in 180 Städten auf der ganzen Welt erhalten.

Sie können ab jetzt time.cloudflare.com als Zeit-Quelle für alle Ihre Geräte mit NTP nutzen, während NTS-Clients sich noch in der Entwicklung befinden. NTPsec beinhaltet experimentelle Unterstützung für NTS. Wenn Sie über Updates bezüglich der NTS-Client-Entwicklung informiert werden wollen, senden Sie uns eine E-Mail an [email protected]. Um NTS zum Schutz der Zeitsynchronisation zu nutzen, wenden Sie sich bitte an Ihre Anbieter und erkundigen Sie sich nach NTS-Support.

Bereits 2015 stieß ich als frischgebackene Absolventin mit Interesse für Internetsicherheit auf dieses eher esoterische Internetprotokoll namens Network Time Protocol (NTP). NTP wurde entwickelt, um die Zeit zwischen Computersystemen zu synchronisieren, die über unzuverlässige Netzwerkpfade mit variabler Latenz kommunizierten. Ich beschäftigte mich damals mit der Sicherheit des Internet-Routings, insbesondere mit Angriffen auf die Resource-Public-Key-Infrastruktur (RPKI), und geriet wegen eines Cache-Flushing-Problems immer wieder in eine Sackgasse. Als letzten Versuch entschied ich mich, die Zeit auf meinem Computer manuell zurückzusetzen, und der Angriff funktionierte.

Ich hatte die Bedeutung von Zeit für die Computersicherheit entdeckt. Die meisten Kryptografien verwenden Zeitstempel, um die Gültigkeitsdauer von Zertifikaten und Signaturen zu begrenzen. Beim Verbinden mit einer Website stellt die Kenntnis der richtigen Zeit sicher, dass das angezeigte Zertifikat aktuell ist und nicht von einem Angreifer kompromittiert wurde. Beim Betrachten von Protokollen stellt die Zeitsynchronisation sicher, dass Ereignisse auf verschiedenen Rechnern genau korreliert werden können. Zertifikate und Protokollierungsinfrastrukturen können aufgrund eines Zeitunterschieds von Minuten, Stunden oder Monaten ausfallen. Andere Anwendungen wie Caching und Bitcoin reagieren schon auf sehr kleine Zeitunterschiede in der Größenordnung von Sekunden empfindlich.

Die Zwei-Faktor-Authentifizierung mit wechselnden Zahlen ist ebenfalls auf präzise Uhren angewiesen. Dadurch ergibt sich die Notwendigkeit, dass Computeruhren Zugriff auf eine relativ genaue Zeit haben, die sicher bereitgestellt wird. NTP ist das am häufigsten verwendete Protokoll zur Zeitsynchronisation über das Internet. Wenn ein Angreifer Schwachstellen im NTP nutzen kann, um die Zeit auf Computeruhren zu manipulieren, kann er die Sicherheitsgarantien dieser Systeme untergraben.

Motiviert durch die Schwere des Problems entschied ich mich, mir NTP und seine Sicherheit genauer anzusehen. Da die Notwendigkeit der netzwerkübergreifenden Zeitsynchronisation frühzeitig erkennbar war, ist NTP ein sehr altes Protokoll. Die erste standardisierte Version von NTP stammt aus dem Jahr 1985, während die neueste NTP Version 4 im Jahr 2010 fertiggestellt wurde (siehe RFC5905).

Im gängigsten Modus funktioniert NTP so, dass ein Client ein Abfragepaket an einen NTP-Server sendet, der dann mit seiner Uhrzeit antwortet. Der Client schätzt dann die Differenz zwischen seiner Uhr und der Remote-Uhr und versucht dabei, die Netzwerkverzögerung zu kompensieren. Der NTP-Client fragt mehrere Server ab und führt Algorithmen aus, um die beste Schätzung auszuwählen, wobei eindeutig falsche Antworten abgelehnt werden.

Überraschenderweise war die Forschung zu NTP und seiner Sicherheit zu diesem Zeitpunkt nicht sehr aktiv. Davor, Ende 2013 und Anfang 2014, wurden hochkarätige DDoS-Angriffe (Distributed Denial of Service) mithilfe der Verstärkung des Datenverkehrs von NTP-Servern durchgeführt. Angreifer, die in der Lage waren, die IP-Adresse eines Opfers zu fälschen, konnten so mit großen Mengen an Traffic die ins Visier genommenen Domains überfordern. Dies erregte die Aufmerksamkeit einiger Forscher. Diese Angriffe nutzten jedoch keine Fehler im grundlegenden Protokoll-Design aus. Die Angreifer nutzten NTP einfach als gewöhnlichen Bandbreitenmultiplikator. Cloudflare schrieb ausführlich über diese Angriffe. Sie können darüber hier, hier und hier lesen.

Ich fand mehrere Fehler im NTP-Kerndesign und dessen Implementierung, die von Netzwerkangreifern ausgenutzt werden könnten, um viel verheerendere Angriffe zu starten, indem die Zeit verschoben oder der Dienst für NTP-Clients verweigert wird. Noch beunruhigender war, dass diese Angreifer kein Monster-In-The-Middle (MITM) sein müssen, der den Datenverkehr zwischen Client und Server ändert, um diese Angriffe zu starten. Eine Reihe neuerer Forschungsarbeiten, die von mir oder meinen Kollegen mitverfasst wurden, zeigten, dass ein Off-Path-Angreifer, der sich irgendwo im Netzwerk befindet, die Zeit verschieben oder den Dienst für NTP-Clients verweigern kann. Eine der Möglichkeiten dafür ist der Missbrauch der IP-Fragmentierung.

Fragmentierung ist eine Funktion der IP-Schicht, bei der ein großes Paket in mehrere kleinere Fragmente aufgeteilt wird, sodass sie durch Netzwerke geleitet werden können, die keine großen Pakete unterstützen. Grundsätzlich kann jedes zufällige Netzwerkelement auf dem Pfad zwischen Client und Server ein spezielles „ICMP-Fragmentierung notwendig“-Paket mit der Aufforderung an den Server senden, das Paket auf X Byte zu fragmentieren. Da vom Server nicht erwartet wird, dass er die IP-Adressen aller Netzwerkelemente auf seinem Pfad kennt, kann dieses Paket von jeder Quell-IP gesendet werden.

Fragmentierungsangriff auf NTP

Bei unserem Angriff nutzt der Angreifer diese Funktion aus, um den NTP-Server dazu zu veranlassen, sein NTP-Antwortpaket für den NTP-Client des Opfers zu fragmentieren. Der Angreifer schickt dann sorgfältig gefertigte, überlappende Antwortfragmente aus dem Off-Path-Bereich, die die Zeitstempelwerte des Angreifers enthalten. Durch die weitere Ausnutzung der Reassembly-Richtlinien für überlappende Fragmente bringt der Angreifer den Client dazu, ein Paket mit legitimen Fragmenten und den Einfügungen des Angreifers zusammenzusetzen. Dadurch werden die Authentizitätsprüfungen umgangen, die auf Werten in den ursprünglichen Teilen des Pakets basieren.

Als NTP im Jahr 1985 geschaffen wurde, gab es zwei Hauptziele für den von NTP bereitgestellten Dienst. Erstens wollte man, dass es robust genug ist, um mit Netzwerkfehlern und Geräteausfällen umzugehen. Es wurde daher als ein Dienst konzipiert, bei dem der Client Timing-Muster von mehreren Peers über mehrere Kommunikationspfade sammeln und sie dann mitteln kann, um eine genauere Messung zu erhalten.

Das zweite Ziel war die Lastverteilung. Während jeder Client mit Zeit-Servern sprechen will, die direkt an hochpräzise Zeitmessgeräte wie Atomuhren, GPS usw. angeschlossen sind und somit eine genauere Zeit haben, ist die Kapazität dieser Geräte begrenzt. Um die Protokolllast im Netzwerk zu reduzieren, wurde der Dienst deshalb hierarchisch aufgebaut. An der Spitze der Hierarchie befinden sich Server, die mit Nicht-NTP-Zeitquellen verbunden sind; diese verteilen die Zeit an andere Server, und diese verteilen sie wiederum an andere Server. Die meisten Computer stellen eine Verbindung zu diesen Servern der zweiten oder dritten Ebene her.

Die Schichtenhierarchie von NTP

Die ursprüngliche Spezifikation (RFC 958) nennt auch die „Nicht-Ziele“ des Protokolls, nämlich Peer-Authentifizierung und Datenintegrität. In dem relativ kleinen und vertrauensvollen frühen Internet wurde Sicherheit nicht als kritisch angesehen, und die Protokolle und Anwendungen, die auf Zeit für Sicherheit angewiesen sind, gab es damals noch nicht. Der Schutz von NTP spielte gegenüber der Verbesserung des Protokolls und der Implementierung eine untergeordnete Rolle.

Mit dem Wachstum des Internets wurden immer mehr Kernprotokolle des Internets zum Schutz vor Missbrauch durch Kryptografie gesichert: TLS, DNSSEC, RPKI sind alle Schritte zur Gewährleistung der Sicherheit der gesamten Kommunikation im Internet. Diese Protokolle verwenden „Zeit“, um Sicherheitsgarantien zu bieten. Da die Sicherheit des Internets von der Sicherheit von NTP abhängt, wird es immer wichtiger, NTP zu schützen.

Diese Forschung zeigte deutlich die Notwendigkeit der Sicherung des NTP. Infolgedessen gab es mehr Arbeit für die Normungsorganisation für Internetprotokolle, die Internet Engineering Task Force (IETF), um NTP kryptografisch zu authentifizieren. Obwohl NTPv4 damals sowohl die symmetrische als auch die asymmetrische kryptografische Authentifizierung unterstützte, wurde es in der Praxis aufgrund der Beschränkungen der beiden Ansätze nur selten verwendet.

Der symmetrische Ansatz von NTPv4 zur Sicherung der Synchronisation skaliert nicht, da der symmetrische Schlüssel vorab geteilt und manuell konfiguriert werden muss: Wenn jeder Client auf der Erde einen speziellen geheimen Schlüssel für die Server bräuchte, von denen er die Zeit erhalten will, hätten die Organisationen, die diese Server betreiben, sehr großen Aufwand mit Verwaltung von Schlüsseln. Dies macht diese Lösung ziemlich umständlich für öffentliche Server, die Abfragen von beliebigen Clients akzeptieren müssen. Zur Illustration: NIST betreibt wichtige öffentliche Zeit-Server und vergibt symmetrische Schlüssel nur an Benutzer, die sich einmal jährlich per Briefpost oder Fax registrieren. Das US Naval Office tut etwas Ähnliches.

Der erste Versuch, das Problem der Schlüsselverteilung zu lösen, war das in RFC 5906 beschriebene Autokey-Protokoll. Viele öffentliche NTP-Server unterstützen Autokey nicht (z. B. die NIST- und USNO-Zeitserver sowie viele Server in pool.ntp.org). Das Protokoll ist überaus anfällig,da jeder Netzwerkangreifer den geheimen Schlüssel, der von Client und Server gemeinsam genutzt wird, ganz einfach abrufen kann. Die Authentifizierungsmechanismen sind nicht standardisiert und recht eigenwillig.

Die Zukunft des Internets ist ein sicheres Internet, also ein authentifiziertes und verschlüsseltes Internet. Doch bis heute ist NTP trotz der fortschreitenden Protokollentwicklung weitgehend unsicher. Und im Laufe der Zeit sind immer mehr Dienste davon abhängig geworden.

Zeitleiste der NTP-Entwicklung

Nach der Veröffentlichung unserer Forschungsarbeit gab es viel mehr Begeisterung für die Verbesserung des Zustands der NTP-Sicherheit in der NTP-Community bei der Normungsorganisation für Internet-Protokolle, der Internet Engineering Task Force (IETF), und auch außerhalb der IETF. Als kurzfristige Lösung wurde die ntpd-Referenzimplementierungssoftware für mehrere von uns gefundene Schwachstellen gepatcht. Und hinsichtlich einer langfristigen Lösung erkannte die Community den dringenden Bedarf an einem sicheren, authentifizierten Zeitsynchronisationsprotokoll auf Basis der Public-Key-Kryptografie, die Verschlüsselung und Authentifizierung ermöglicht, ohne dass zuvor das Schlüsselmaterial ausgetauscht werden muss. Heute haben wir dank der Arbeit von Dutzenden engagierten Personen in der NTP-Arbeitsgruppe einen Network Time Security (NTS)-Entwurf bei der IETF.

Kurz gesagt, das NTS-Protokoll ist in zwei Phasen unterteilt. Die erste Phase ist der NTS-Schlüsselaustausch, der das erforderliche Schlüsselmaterial zwischen dem NTP-Client und dem Server festlegt. Diese Phase verwendet den TLS-Handshake (Transport-Layer-Security-Handshake) und basiert auf der gleichen Public-Key-Infrastruktur wie das Web. Sobald die Schlüssel ausgetauscht sind, wird der TLS-Kanal geschlossen und das Protokoll tritt in die zweite Phase ein. In dieser Phase werden die Ergebnisse des TLS-Handshakes verwendet, um NTP-Zeitsynchronisationspakete über Erweiterungsfelder zu authentifizieren. Weitere Informationen finden Sie im Internet-Entwurf.

Heute führt Cloudflare seinen kostenlosen Zeit-Dienst für jeden im Internet ein. Wir wollen die Beschränkungen der bestehenden öffentlichen Zeit-Dienste beseitigen, insbesondere durch Erhöhung der Verfügbarkeit, Robustheit und Sicherheit.

Wir nutzen unser globales Netzwerk, um niedrigere Latenz und höhere Genauigkeit zu bieten. Unsere 180 Standorte auf der ganzen Welt verwenden Anycast, um Ihre Pakete automatisch an unseren nächstgelegenen Server weiterzuleiten. Alle unsere Server werden mit Schicht-1-Zeit-Dienst-Anbietern synchronisiert und bieten dann NTP für die breite Öffentlichkeit an, ähnlich wie auch andere öffentliche NTP-Anbieter. Die größte Quelle für Ungenauigkeiten bei Zeitsynchronisationsprotokollen ist die Netzwerkasymmetrie, die zu einem Unterschied in den Laufzeiten zwischen Client und Server und zurück vom Server zum Client führt. Die Nähe unserer Server zu den Nutzern bedeutet jedoch, dass es weniger Jitter – ein Messwert für die Varianz der Latenz im Netzwerk – und mögliche Asymmetrien in den Paketpfaden geben wird. Wir hoffen außerdem, dass unser Dienst in Regionen mit einem Mangel an NTP-Servern die Kapazität und Qualität des NTP-Ökosystems erheblich verbessert.

Cloudflare-Server erhalten authentifizierte Zeit, indem sie einen gemeinsamen symmetrischen Schlüssel mit unseren Schicht-1-Upstream-Servern verwenden. Diese Upstream-Server sind geografisch verteilt und stellen sicher, dass die Server in unseren Rechenzentren die genaue Zeit haben. Aber dieser Ansatz zur Sicherung der Zeit ist nicht skalierbar. Wir mussten E-Mails mit den einzelnen Organisationen austauschen, die Schicht-1-Server betreiben, und die Erlaubnis zur Nutzung aushandeln. Obwohl dies eine Lösung für uns ist, ist es keine Lösung für alle im Internet.

Als sicherer Zeit-Dienst-Anbieter ist Cloudflare stolz darauf, bekannt geben zu können, dass wir zu den ersten gehören, die einen kostenlosen und sicheren öffentlichen Zeit-Dienst auf Basis der Network Time Security anbieten. Wir haben den neuesten IETF-Entwurf für NTS implementiert. Während dieser Entwurf den Prozess für Internetstandards durchläuft, sind wir bestrebt, unseren Dienst auf dem neuesten Stand zu halten.

Die meisten NTP-Implementierungen arbeiten derzeit an der Unterstützung von NTS. Wir gehen davon aus, dass in den nächsten Monaten eine breitere Einführung sowie die Weiterentwicklung des aktuellen Protokollentwurfs zu einem RFC erfolgen werden. Derzeit haben wir Interoperabilität mit NTPsec, in dem Entwurf 18 von NTS umgesetzt ist. Wir hoffen, dass unser Dienst eine schnellere Akzeptanz dieser wichtigen Verbesserung der Internetsicherheit bewirken wird. Da es sich um einen neuen Dienst ohne Notwendigkeit der Abwärtskompatibilität handelt, verlangen wir die Verwendung von TLS v1.3, um die Verwendung der sichersten TLS-Version zu fördern.

Wenn Sie über einen NTS-Client verfügen, richten Sie ihn so ein, dass er auf time.cloudflare.com:1234 zeigt. Andernfalls richten Sie Ihren NTP-Client auf time.cloudflare.com. Weitere Details zur Konfiguration finden Sie in der Entwicklerdokumentation.

Von unserem Roughtime-Dienst bis hin zu Universal SSL hat Cloudflare dazu beigetragen, die Verfügbarkeit und den Einsatz sicherer Protokolle zu erweitern. Mit unserem kostenlosen öffentlichen Zeit-Dienst bieten wir nun eine vertrauenswürdige, allgemein verfügbare Alternative zu einem weiteren unsicheren Legacy-Protokoll. Das ist Teil unserer Mission, das Internet für alle schneller, zuverlässiger und sicherer zu machen.

Mein Dank geht an die vielen anderen Entwickler, die an diesem Projekt mitgearbeitet haben, darunter Watson Ladd, Gabbi Fisher, und Dina Kozlov

Dieser Beitrag stammt von Aanchal Malhotra, Graduate Research Assistant an der Boston University und ehemalige Cloudflare-Praktikantin im Cryptography-Team.