#dnsquery

Perché il Piracy Shield non funziona e come sarebbe dovuto essere implementato. Nell’era digitale, la gestione della proprietà intellettuale e la lotta contro la pirateria online rappresentano sfide cruciali per i regolatori, le industrie creative e i fornitori di servizi internet. Il “Piracy Shield”, un’iniziativa dell’Autorità per le Garanzie nelle Comunicazioni (AGCOM), rappresenta un tentativo significativo di affrontare il problema della pirateria digitale in Italia. Questo strumento è stato ideato per identificare e bloccare l’accesso ai siti web che violano i diritti di proprietà intellettuale, sfruttando tecnologie di filtraggio degli  “FQDN e degli indirizzi IP” (citando testualmente AGCOM). Nonostante le sue nobili intenzioni, il Piracy Shield ha suscitato non poche controversie e dibattiti riguardo la sua efficacia e le implicazioni per la libertà di espressione e il diritto alla privacy. In questo articolo tecnico-scientifico, si intende esplorare e discutere le ragioni per cui il Privacy Shield non ha raggiunto pienamente i suoi obiettivi, mettendo in luce le difficoltà tecniche, legali e etiche incontrate.

Sarà inoltre illustrato come, attraverso un approccio innovativo basato sulla configurazione di record CNAME, sia possibile distinguere tra servizi legittimi e illeciti associati allo stesso indirizzo IPv4. Questa dimostrazione pratica non solo evidenzierà le potenzialità di tali tecniche, ma anche come esse potrebbero essere integrate efficacemente in un framework rinnovato per la lotta alla pirateria, suggerendo modifiche e migliorie al sistema attuale del Piracy Shield. Le Content Delivery Network Le Content Delivery Networks (CDN) sono infrastrutture distribuite di server progettate per ottimizzare la consegna di contenuti web agli utenti finali. Le CDN migliorano la velocità e l’affidabilità di accesso ai dati riducendo la distanza fisica tra il server e l’utente, distribuendo il contenuto su diversi server posizionati in varie località geografiche. Funzionamento delle CDN Quando un utente accede a un sito web che utilizza una CDN, la richiesta di dati non viene inviata direttamente al server principale del sito, ma viene reindirizzata al server della CDN più vicino all’utente. Questo server “edge” contiene copie dei contenuti del sito, come file HTML, immagini, video e altri tipi di dati. Grazie a questa architettura, il tempo di caricamento delle pagine si riduce notevolmente, migliorando l’esperienza dell’utente e riducendo il carico sui server centrali. Mascheramento dell’IP reale Un effetto importante dell’uso delle CDN è il mascheramento dell’indirizzo IP pubblico reale del server di origine dei contenuti. Quando un servizio online adotta una CDN, gli indirizzi IP visibili al pubblico sono quelli dei server della rete CDN. Questo significa che l’IP percepito come fonte del servizio è in realtà quello della CDN, non del server originale. Questo ha implicazioni per la sicurezza, la privacy e la gestione del traffico, ma può anche complicare alcune operazioni di controllo e filtraggio del contenuto. Implicazioni per il filtraggio di contenuti Se un’autorità come AGCOM implementa misure per bloccare l’accesso a contenuti ritenuti illegali (come quelli piratati) mediante il filtraggio degli indirizzi IP attraverso strumenti come il Piracy Shield, si potrebbero verificare problemi significativi. Poiché un singolo indirizzo IP di una CDN può essere utilizzato per trasmettere i contenuti di numerosi servizi diversi, il blocco di quell’IP potrebbe avere l’effetto collaterale di interrompere l’accesso a servizi legittimi e non solo a quelli illegali. Questo scenario potrebbe portare a interruzioni di servizio per utenti che non sono coinvolti nella fruizione di contenuti piratati. Facciamo chiarezza con un esempio pratico Per comprendere meglio come funziona la navigazione su internet e l’interazione con una Content Delivery Network (CDN), prendiamo come esempio il processo di collegamento a un sito web, come “www.libero.it”. Questo esempio ci permetterà di osservare come, durante la navigazione, il nome di dominio inizialmente richiesto possa in realtà essere servito da un dominio completamente diverso, come “d31d9gezsyt1z8.cloudfront.net”, che appartiene a una CDN. DNS Query Il processo inizia quando l’utente digita “www.libero.it” nel browser. Il browser deve risolvere questo nome di dominio in un indirizzo IP per poter stabilire una connessione. Questo avviene tramite una richiesta DNS (Domain Name System). Il browser consulta i server DNS configurati (tipicamente forniti dal provider di servizi internet o specificati manualmente dall’utente) per ottenere l’indirizzo IP associato al nome di dominio. (Si vede evidenziata la richiesta) Ricezione della risposta DNS I server DNS eseguono la ricerca e, una volta trovato l’indirizzo IP, lo restituiscono al browser. Se il dominio è ospitato su una CDN, l’IP restituito sarà quello di uno dei server edge della CDN più vicino all’utente, non l’IP del server originale di “libero.it”. (Si vede evidenziata la risposta Apertura della connessione (Handshake) Con l’indirizzo IP in mano, il browser inizia un handshake TCP con il server al fine di stabilire una connessione affidabile. Questo include la sincronizzazione dei numeri di sequenza per garantire che i pacchetti di dati vengano inviati e ricevuti in ordine. Durante l’handhsake il client invia un segmento SYN , il server risponde con un SYN + ACK , il client termina l’handshake con un ACK. (Si vede in figura nella riga evidenziata l’inizio dell’handshake verso la CDN di libero).

Negoziazione TLS (Transport Layer Security) Dopo aver stabilito una connessione TCP, il browser inizia una negoziazione TLS per assicurare che la comunicazione sia sicura e criptata. Questo processo inizia con l’invio del “ClientHello”, che include la versione di TLS supportata, i metodi di cifratura proposti, e altri dettagli necessari per la sicurezza.

Il server risponde con un “ServerHello”, che conferma i dettagli della crittografia che sarà utilizzata, seleziona un metodo di cifratura tra quelli proposti dal client e prosegue con l’invio dei certificati, la verifica della chiave, e la conferma finale di inizio della cifratu Comunicazione sicura Una volta completata la negoziazione TLS, tutte le trasmissioni successive tra il browser e il server sono completamente criptate. Il browser può ora richiedere le risorse web da “www.libero.it”, che in realtà potrebbero essere servite dal dominio della CDN, come “d31d9gezsyt1z8.cloudfront.net”. Questo esempio mostra come, nella pratica, un sito che l’utente intende visitare possa essere effettivamente distribuito attraverso una rete CDN, rendendo il nome del dominio CDN visibile nelle comunicazioni di rete, anche se l’utente potrebbe non essere immediatamente consapevole di tale fatto. Considerazioni Questa architettura farà in modo che www.libero.it avrà una serie di IP associati all’ASN di cloudfront che vengono usati per far funzionare la CDN. Questi IP saranno associati non solo a www.libero.it ma anche a molti altri FQDN (Altre web app) che usano la CDN. Ricordiamo che questi servizi vengono distinti fra loro grazie ai record CNAME che puntano a FQDN univoci come questo: d31d9gezsyt1z8.cloudfront.net.

Dimostrazione del problema Con l’esempio precedente abbiamo quindi dimostrato che quando un servizio è integrato ad una CDN la corrispondenza servizio – IP non è più della cardinalità 1:1 , ma bensì N:1. Quindi se viene filtrato un indirizzo IP, N servizi vengono oscurati, pur non essendo tutti illegali. Lo abbiamo visto con l’esempio precedente in cui libero viene deliberatamente associato a diversi IP, condivisi con altri servizi della CDN cloudFront. Infatti una delle CDN che ha lamentato proprio questo problema è la nota Cloudflare che ha emesso un comunicato ad alcuni suoi clienti, esortandoli all’invio di una lettera di richiamo alla stessa AGCOM chiedendo di annullare l’ingiusto provvedimento.