Zurück zum Blog
dns Veröffentlicht: AEU DNS Newsroom

Public Suffix List sieht sich Forderungen nach einem sichereren Nachfolger gegenüber

Public Suffix List sieht sich Forderungen nach einem sichereren Nachfolger gegenüber
KI-generiertes Bild

Der in Browser integrierten Public Suffix List werden uneinheitliche Aktualisierungen, eingeschränkter Zugang und eine schwache Kontrolle der Betreiber über Domain-Grenzen vorgeworfen.

Die Public Suffix List, kurz PSL, steht erneut in der Kritik, weil Browser und andere Sicherheitssysteme damit bestimmen, wo eine unabhängig kontrollierte Internet-Domain endet und eine andere beginnt. Ein von CircleID veröffentlichter Kommentar argumentiert, dass die von Freiwilligen gepflegte Textdatei zu einem Sicherheitsrisiko geworden sei, weil verschiedene Nutzer unterschiedliche Versionen erhalten, Anwender sie uneinheitlich interpretieren und Domain-Betreiber ihre eigenen Grenzen nicht direkt festlegen können.

Die PSL enthält einen Suffix pro Zeile. Ein public suffix ist eine Domain-Endung, unterhalb derer unterschiedliche Personen oder Organisationen separate Namen registrieren oder kontrollieren können. Ihr ICANN-Bereich umfasst Top-Level-Domains und von Registries betriebene Endungen wie „com“, „net“ und „co.uk“. Ihr PRIVATE-Bereich deckt Dienste wie „github.io“ ab, bei denen Adressen wie „alice.github.io“ Inhalte enthalten können, die von Nutzern kontrolliert werden, die einander nicht vertrauen. Mozilla entwickelte diesen Ansatz Mitte der 2000er-Jahre, damit Firefox cookie isolation durchsetzen konnte, sodass eine Website kleine Mengen von Browserdaten nicht unzulässigerweise mit einer anderen Website teilte, die als unabhängig behandelt wurde.

Die Liste wurde anschließend zur De-facto-Referenz für viele weitere Entscheidungen über Domain-Grenzen. Browser integrieren in jede Veröffentlichung einen Snapshot, sodass unterschiedliche Versionen verschiedene Kopien enthalten können. Dem CircleID-Kommentar zufolge sind Versionsabweichungen häufig, Rollbacks äußerst schwierig und einzelne Anwender wenden die Grenzen nicht immer auf die gleiche Weise an. Browser nutzen die Liste inzwischen für Site-Isolation-Schutzmechanismen sowie zur Trennung von Zustand und Speicher, also der gespeicherten Informationen, die verschiedenen Websites zugeordnet sind.

Auch andere Systeme haben sie übernommen. Certificate authorities, also Organisationen, die digitale Zertifikate für sichere Website-Verbindungen ausstellen, verwenden sie unter anderem für Rate-Limit-Berechnungen. Let’s Encrypt wird als ein Beispiel genannt. Empfangssysteme, die DMARC implementieren, eine Richtlinie zur E-Mail-Authentifizierung, haben sie zur Ermittlung einer organisatorischen Domain verwendet. WebAuthn, der Webstandard hinter Passkeys und anderen starken Anmeldemethoden, prüft den Relying Party Identifier einer Website anhand der Liste. Dieser Identifier legt fest, welche Website einen Berechtigungsnachweis verwenden darf. Dem Kommentar zufolge sind viele weitere Anwendungsfälle entstanden, obwohl die PSL-Freiwilligen eingeräumt haben, dass die Datei nicht für jede Rolle konzipiert wurde, die sie heute erfüllt, und dass die verfügbaren Ressourcen für ihre Pflege nicht ausreichen.

Die zentrale Kritik betrifft die Kontrolle durch Betreiber. Fehlt eine gemeinsam genutzte übergeordnete Domain in der PSL, kann ein Browser auf ihre Hostnames eine weniger restriktive Richtlinie anwenden. Das kann relevant sein, wenn getrennte, einander nicht vertrauende Nutzer Inhalte auf verschiedenen Subdomains veröffentlichen. Dem Kommentar zufolge können Betreiber die mit einer PSL-Anerkennung verbundene verstärkte Isolierung nicht eigenständig verlangen. Sie müssen die Aufnahme beantragen, und die derzeitige Aufnahmepraxis verlangt Berichten zufolge von Plattformen den Nachweis von Nutzerzahlen im Bereich vieler Tausend. Der Autor argumentiert, dass dies kleine Dienste und Start-ups benachteilige.

Dieses Modell unterscheidet sich von anderen Sicherheitsmechanismen für das Web und DNS, die von einem Domain-Inhaber kontrolliert werden. Der Kommentar verweist auf CAA und TLSA, die zertifikatsbezogene Richtlinien ausdrücken, auf DS records, die eine Domain mit DNSSEC verbinden, dem System zur Überprüfung der Authentizität von DNS-Antworten, auf HSTS, das Browser anweist, HTTPS zu verlangen, sowie auf CSP, das begrenzt, welche Ressourcen eine Webseite laden darf. Diese Mechanismen können über DNS records oder Web-Header konfiguriert werden. Die PSL bietet keine gleichwertige Self-Service-Deklaration, sodass ihre Entscheidungen über Domain-Grenzen in einer externen Datei verbleiben.

Der Artikel weist Browser-Entwicklern erhebliche Verantwortung zu. Berichten zufolge liefert jeder große Browser eine PSL-Version aus, während Mozilla als Anbieter beschrieben wird, der umfangreichere Unterstützung als die meisten anderen leistet. Browser-Hersteller haben DNS-basierte Alternativen aus Sorge vor zusätzlichen Verzögerungen durch DNS lookups und wegen der Datenintegrität abgelehnt. DBOUND, ein Vorhaben zur Entwicklung einer standardisierten Methode für die Ermittlung von Domain-Grenzen, erreichte nicht genügend Konsens, um über seine Arbeitsgruppe hinaus voranzukommen. Ein an dieser Arbeit beteiligter Co-Editor erklärte, Browser-Entwickler hätten deutlich gemacht, dass sie keinen weiteren DNS lookup zur Bestimmung von Cookie-Grenzen wollten und eine statische, integrierte Liste für ausreichend hielten.

Auch die Dateigröße hat die Auswahl der Einträge beeinflusst. PSL-Freiwillige haben erklärt, Browser-Hersteller wollten die Liste klein halten, was Beschränkungen dafür begünstige, welche privaten Suffixe aufgenommen werden. Der Kommentar stellt dieses Argument infrage, indem er die rund 10.000 Einträge der PSL mit den HSTS-Preload-Listen von Browsern vergleicht, die ungefähr 95.000 bis 172.000 Einträge enthalten. Er verweist außerdem auf einen Bericht, wonach geeignete Chrome-Installationen möglicherweise ein 4-GB-Gemini-Modell herunterladen. Nach Ansicht des Autors schützt die Begrenzung des PSL-Wachstums Browser vor dem Druck, einen Ersatz zu entwickeln, und bevorzugt zugleich größere Plattformen.

Es gibt bereits ein bedeutendes Beispiel für die Abkehr von der Liste. RFC 9989, laut Kommentar die neueste DMARC-Spezifikation, schreibt die PSL nicht mehr vor. Der frühere RFC 7489 hatte die Abhängigkeit als unvollkommen bezeichnet und vorgesehen, eine zuverlässigere und sicherere Methode einzuführen, sobald eine solche allgemein verfügbar wäre. Ein Co-Editor von RFC 9989 erklärte in einer Antwort, dass DMARC-Nutzer, Softwareentwickler und Anbieter nach einem Jahrzehnt praktischer Erfahrung zusammenarbeiteten, untersuchten, ob die Änderung zu Störungen führen würde, und sich auf die Aktualisierung ihrer Werkzeuge einigten.

Die Forderung, die PSL außer Betrieb zu nehmen, ist umstritten. Ein Befragter argumentierte, die Kritik solle sich in erster Linie an Browser richten und über Standardisierungsorganisationen wie die IETF, das CA/Browser Forum, das W3C oder WHATWG vorgebracht werden, statt sich gegen Freiwillige zu richten. Der Co-Editor von RFC 9989 stellte zudem infrage, ob die Einschränkungen der PSL über bestimmte Anwendungsfälle hinaus ein allgemeineres Problem darstellen. Der Kommentar kommt dennoch zu dem Schluss, dass ein Ersatz weniger an der technischen Machbarkeit scheitere als an der Schwierigkeit, die Interessen von Browsern, Certificate authorities und DNS-Akteuren aufeinander abzustimmen, da keine einzelne Standardisierungsorganisation dafür aufgestellt sei, sie alle zu koordinieren.

Für Leser, die den Datenschutz von Resolvern getrennt von der Verarbeitung von Domain-Grenzen durch Browser betrachten, bietet AEU DNS privates und sicheres DNS für alle. Ein privater DNS-Dienst ersetzt nicht die in Browser integrierte PSL. Website-Betreiber mit Subdomains für mehrere Nutzer müssen daher weiterhin das Browser-Verhalten, den Status der Liste und die relevanten Standards beobachten.

Das praktische Problem besteht nicht darin, dass die PSL plötzlich versagt hätte, sondern darin, dass eine ursprünglich für die Trennung von Browser-Cookies erstellte Liste heute Zertifikate, E-Mail-Authentifizierung, Passkeys und mehrere Formen der Isolierung von Browser-Speicher beeinflusst. Ob sie abgeschafft werden sollte, bleibt umstritten. Ihre statische Verteilung, uneinheitlichen Versionen und die fehlende direkte Kontrolle durch Betreiber sind jedoch konkrete Einschränkungen, mit denen sich jeder Nachfolger befassen müsste.

Begriffe erklärt

Public Suffix List
Eine in Browser integrierte Liste, mit der bestimmt wird, wo unabhängig kontrollierte Domain-Namen beginnen und enden.
public suffix
Eine Domain-Endung, unterhalb derer verschiedene Personen oder Organisationen separate Namen kontrollieren können.
cookie isolation
Eine Trennung im Browser, die verhindert, dass eine unabhängige Website gespeicherte Website-Daten unzulässigerweise mit einer anderen teilt.
DMARC
Domain-based Message Authentication, Reporting and Conformance ist eine Richtlinie zur Prüfung und Behandlung von E-Mails, die vorgeben, von einer bestimmten Domain zu stammen.
WebAuthn
Ein Webstandard, mit dem Websites Passkeys und andere starke Anmeldemethoden verwenden können.
DNSSEC
Domain Name System Security Extensions ermöglichen Software die Prüfung, ob eine DNS-Antwort authentisch ist und nicht verändert wurde.
HSTS
HTTP Strict Transport Security weist einen Browser an, eine Verbindung zu einer Website ausschließlich über verschlüsseltes HTTPS herzustellen.
CSP
Content Security Policy beschränkt, welche Ressourcen und welcher Code von einer Webseite geladen werden dürfen.

So schützen Sie sich

  1. Aktivieren Sie automatische Browser-Updates, damit Sie neuere Snapshots der Public Suffix List erhalten, die in Browser-Veröffentlichungen enthalten sind.
  2. Wenn Kunden Inhalte auf separaten Subdomains veröffentlichen, bitten Sie Ihren Entwickler zu prüfen, ob Anmeldungen, Cookies und gespeicherte Browserdaten in den aktuellen großen Browsern weiterhin voneinander getrennt bleiben.
  3. Prüfen Sie, ob Ihre gemeinsam genutzte Domain in der offiziellen Public Suffix List aufgeführt ist, statt davon auszugehen, dass Browser jede Kunden-Subdomain unabhängig behandeln.
  4. Wenn Ihre Organisation DMARC zum Schutz von E-Mails verwendet, fragen Sie Ihren E-Mail-Anbieter, ob seine Werkzeuge RFC 9989 unterstützen.
  5. Gehen Sie nicht davon aus, dass ein Wechsel Ihres DNS-Anbieters die in Ihrem Browser festgelegten Domain-Grenzen verändert; behandeln Sie diese als getrennte Sicherheitskontrollen.
Holen Sie sich privates, verschlüsseltes DNS