Perché il Piracy Shield non funziona e come sarebbe dovuto essere implementato

Giuseppe Longobardi : 15 Aprile 2024 08:10

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 cifratura.

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.

Non si può quindi pensare di bloccare il traffico IP semplicemente filtrando un indirizzo IPv4/IPv6.

Come si potrebbe procedere

Per affrontare efficacemente le sfide poste dal filtraggio di contenuti attraverso indirizzi IP in un ambiente dove sono ampiamente utilizzate le Content Delivery Networks (CDN), è essenziale adottare metodi più sofisticati che prendano in considerazione le peculiarità tecniche delle CDN stesse. Una strategia più mirata e meno suscettibile di causare danni collaterali può essere implementata analizzando in dettaglio le proprietà di rete associate agli indirizzi IP, in particolare l’Autonomous System Number (ASN).

Analisi dell’ASN

Prima di procedere al blocco di un indirizzo IP sospettato di veicolare contenuti piratati, è cruciale determinare a quale sistema autonomo appartiene quel determinato IP. Se l’IP è associato all’ASN di una CDN nota, questo indica che potrebbe essere utilizzato per servire una moltitudine di clienti e servizi, molti dei quali legittimi. Il blocco diretto di tali IP potrebbe quindi interrompere l’accesso a servizi legittimi, causando interruzioni non necessarie e potenzialmente estese.

Blocco basato su FQDN della CDN

Invece di bloccare indiscriminatamente gli indirizzi IP, si dovrebbe valutare l’opzione di filtrare specifici Fully Qualified Domain Names (FQDN) direttamente legati a contenuti illeciti. Un metodo più mirato consiste nell’analizzare i record CNAME, che collegano un FQDN a un altro dominio, spesso usato per identificare contenuti specifici all’interno di una CDN.

Il sistema attuale del Piracy Shield già applica il blocco agli FQDN e agli indirizzi IP, ma non estende questo trattamento ai FQDN univoci usati dalle CDN. Ad esempio, bloccando il dominio pubblico www.libero.it ed i suoi indirizzi IP, si impedisce anche l’accesso agli IP come 18.66.196.87, 18.66.196.23, 18.66.196.13 e 18.66.196.59. Tali indirizzi, associati a una CDN, vengono utilizzati anche da altri servizi che sarebbero ingiustamente bloccati.

Soluzione proposta

Quando viene rilevato che un servizio usa una CDN, la strategia corretta sarebbe quella di bloccare esclusivamente gli FQDN specifici alla CDN, come d31d9gezsyt1z8.cloudfront.net e www.libero.it, senza intervenire sugli indirizzi IP. 

In questo modo gli altri servizi che usano la CDN non saranno bloccati.

Conclusioni

Adottando queste pratiche migliorate, AGCOM e altre autorità simili potrebbero ottimizzare le loro strategie di enforcement senza suscitare controversie legate a interruzioni di servizio ingiustificate o a violazioni dei diritti alla privacy e alla libertà di espressione. Questo equilibrio tra l’efficacia del blocco e il rispetto per i diritti degli utenti è essenziale per mantenere la fiducia nel regolamento digitale e nella protezione della proprietà intellettuale nel contesto globale e interconnesso di oggi.