La Public Suffix List deve affrontare richieste di un successore più sicuro

La Public Suffix List, o PSL, deve affrontare nuove critiche per il modo in cui i browser e altri sistemi di sicurezza stabiliscono dove termina un dominio Internet controllato in modo indipendente e ne inizia un altro. Un commento pubblicato da CircleID sostiene che il file di testo gestito da volontari sia diventato un rischio per la sicurezza, perché utenti diversi ricevono versioni differenti, i sistemi che lo utilizzano lo interpretano in modo non uniforme e i gestori dei domini non possono dichiarare direttamente i propri confini.

La PSL contiene un suffix per riga. Un public suffix è la parte finale di un dominio sotto la quale persone o organizzazioni diverse possono registrare o controllare nomi separati. La sua sezione ICANN comprende i top-level domain e le terminazioni gestite dai registry, come “com”, “net” e “co.uk”. La sezione PRIVATE comprende servizi come “github.io”, nei quali indirizzi come “alice.github.io” possono contenere materiale controllato da utenti che non si considerano reciprocamente affidabili. Mozilla ideò questo approccio a metà degli anni Duemila affinché Firefox potesse applicare la cookie isolation, evitando che un sito condividesse impropriamente piccoli frammenti di dati del browser con un altro sito considerato indipendente.

In seguito, la lista è diventata il riferimento de facto per molte altre decisioni relative ai confini dei domini. I browser integrano uno snapshot in ogni release, perciò versioni diverse possono includere copie differenti. Il commento di CircleID afferma che il disallineamento tra versioni è comune, che i rollback sono estremamente difficili e che i singoli sistemi che usano la lista non applicano sempre i confini nello stesso modo. Oggi i browser utilizzano la lista per le protezioni di site isolation e per separare state e storage, ossia le informazioni salvate associate a siti diversi.

Anche altri sistemi l'hanno adottata. Le certificate authorities, le organizzazioni che rilasciano certificati digitali per connessioni sicure ai siti web, la utilizzano anche per calcolare i rate limit. Let’s Encrypt è citata come esempio. I sistemi riceventi che implementano Domain-based Message Authentication, Reporting and Conformance (DMARC), una policy di autenticazione delle email, l'hanno usata per identificare un dominio organizzativo. WebAuthn, lo standard web alla base delle passkey e di altri metodi di accesso robusti, verifica rispetto alla lista il Relying Party Identifier di un sito. Questo identificatore stabilisce quale sito web è autorizzato a utilizzare una credenziale. Il commento afferma che si sono sviluppati molti altri utilizzi, anche se i volontari della PSL hanno riconosciuto che il file non è stato progettato per tutti i ruoli che ora svolge e che le risorse disponibili per la sua manutenzione sono insufficienti.

La critica principale riguarda il controllo da parte dei gestori. Se un dominio padre condiviso non è presente nella PSL, un browser può applicare una policy meno restrittiva ai relativi hostname. Ciò può essere importante quando utenti distinti e non reciprocamente affidabili pubblicano contenuti su subdomain differenti. Secondo il commento, i gestori non possono richiedere autonomamente l'isolamento rafforzato associato al riconoscimento nella PSL. Devono presentare una richiesta di inclusione e, secondo quanto riportato, le attuali prassi di accettazione impongono alle piattaforme di dimostrare di avere molte migliaia di utenti. L'autore sostiene che ciò penalizzi i piccoli servizi e le start-up.

Questo modello è diverso da quello di altri meccanismi di sicurezza web e DNS controllati dal proprietario di un dominio. Il commento cita CAA e TLSA, che esprimono policy relative ai certificati; i record DS, che collegano un dominio a DNSSEC, il sistema utilizzato per verificare l'autenticità delle risposte DNS; HSTS, che ordina ai browser di richiedere HTTPS; e CSP, che limita le risorse che una pagina web può caricare. Questi meccanismi possono essere configurati tramite record DNS o header web. La PSL non dispone di una dichiarazione self-service equivalente e lascia le decisioni sui confini all'interno di un file esterno.

L'articolo attribuisce una responsabilità considerevole agli sviluppatori dei browser. Secondo quanto riportato, ogni browser principale distribuisce una versione della PSL, mentre Mozilla viene descritta come l'organizzazione che fornisce un supporto più sostanziale rispetto alla maggior parte delle altre. I produttori di browser si sono opposti alle alternative basate su DNS a causa dei timori relativi ai ritardi provocati da lookup aggiuntivi e all'integrità dei dati. DBOUND, un'iniziativa volta a sviluppare un metodo standard per individuare i confini dei domini, non ha ottenuto un consenso sufficiente per avanzare oltre il proprio working group. Un co-editor coinvolto nel progetto ha affermato che gli sviluppatori dei browser avevano chiarito di non volere un altro DNS lookup per i confini dei cookie e di considerare adeguata una lista statica integrata.

Anche le dimensioni del file hanno influito sulla selezione delle voci. I volontari della PSL hanno affermato che i browser vogliono mantenere piccola la lista, incoraggiando restrizioni sui private suffix ammessi. Il commento contesta questa argomentazione confrontando le circa 10.000 voci della PSL con le HSTS preload list dei browser, che contengono approssimativamente tra 95.000 e 172.000 voci. Cita inoltre un rapporto secondo il quale le installazioni Chrome idonee possono scaricare un modello Gemini da 4 GB. Secondo l'autore, limitare la crescita della PSL protegge i browser dalle pressioni a sviluppare un sostituto, favorendo al contempo le piattaforme più grandi.

Esiste già un esempio significativo di abbandono della lista. RFC 9989, la più recente specifica DMARC identificata nel commento, non richiede più la PSL. Il precedente RFC 7489 aveva descritto questa dipendenza come imperfetta e prevedeva l'adozione di un metodo più affidabile e sicuro, qualora ne fosse diventato generalmente disponibile uno. In una risposta, un co-editor di RFC 9989 ha spiegato che utenti DMARC, sviluppatori software e fornitori hanno collaborato dopo un decennio di esperienza, hanno analizzato se il cambiamento potesse risultare problematico e hanno concordato di aggiornare i propri strumenti.

La richiesta di dismettere la PSL è contestata. Un partecipante alla discussione ha sostenuto che le critiche dovrebbero essere rivolte principalmente ai browser e presentate attraverso organismi di standardizzazione come IETF, CA/Browser Forum, W3C o WHATWG, anziché ai volontari. Anche il co-editor di RFC 9989 ha messo in dubbio che i limiti della PSL costituiscano un problema più ampio al di là di specifici casi d'uso. Il commento conclude tuttavia che la sostituzione è ostacolata non tanto dalla fattibilità tecnica, quanto dalla difficoltà di allineare i soggetti interessati dei browser, delle certificate authorities e del DNS, poiché nessun singolo organismo di standardizzazione è nella posizione di coordinarli tutti.

Per i lettori che valutano la privacy dei resolver separatamente dalla gestione dei confini da parte dei browser, AEU DNS offre un DNS privato e sicuro per tutti. Un servizio DNS privato non sostituisce la PSL integrata nei browser, perciò i proprietari di siti web con subdomain utilizzati da più utenti devono comunque monitorare il comportamento dei browser, lo stato della lista e gli standard pertinenti.

Il problema pratico non è che la PSL abbia improvvisamente smesso di funzionare, ma che una lista creata per separare i cookie nei browser ora influisce sui certificati, sull'autenticazione delle email, sulle passkey e su molteplici forme di storage isolation nei browser. La questione della sua abolizione rimane controversa, ma la distribuzione statica, le versioni non uniformi e la mancanza di controllo diretto da parte dei gestori sono limiti concreti che qualsiasi successore dovrebbe affrontare.