BGP hijacking: l'accusa di Durov sul blocco di Telegram in India

Cloud europeo e sovranità digitale: il bluff del datacenter in EU

La cloud sovranità europea è sovereignty washing: i datacenter sono in UE, le chiavi restano a Seattle. Gaia-X è fallito, NIS2 stringe.

Quando l'India ha staccato Telegram, Pavel Durov non si è fermato alla protesta sul blocco (la cronaca dell'ordine e dell'esame NEET la trovi nel blocco di Telegram in India spiegato). Ha lanciato un'accusa molto più pesante: che un operatore indiano stia dirottando il traffico Telegram di utenti fuori dall'India con una tecnica chiamata BGP hijacking. Parole grosse — e l'occasione perfetta per spiegare cos'è il BGP hijacking, e per fare una cosa che in questi casi si fa troppo poco: separare ciò che è verificabile da ciò che è un'accusa.

Cosa ha detto Durov, parola per parola

Il 16 giugno 2026, sul suo canale X (@durov), Durov ha scritto testualmente:

"Indian telecom Reliance is sabotaging access to Telegram for millions of users OUTSIDE India (including the UAE) via a rogue method called BGP hijacking. The sabotage seems intentional, as Reliance has ignored multiple reports. This may be part of a competitive war, as Reliance is partially owned by Meta — the company behind WhatsApp."

E ha consigliato agli operatori di rete di rifiutare gli annunci di rotta non autorizzati provenienti dall'AS18101.

Dentro questo post ci sono tre affermazioni distinte, e vanno pesate una per una: (a) c'è un BGP hijack in corso; (b) è intenzionale; (c) c'entra Meta. Spoiler: reggono in modo molto diverso.

Prima regola: accusa non è fatto

Attenzione a non ribaltare il ragionamento: "nessun monitor lo conferma" non significa "è dimostrato che non è successo". È un'assenza di prova, non una prova dell'assenza. Tecnicamente l'hijack è plausibilissimo (più sotto vedrai perché). Ma finché non emergono dati di route-collector, resta quello che è: un'accusa del fondatore di Telegram.

La frizione che quasi nessuno nota: "Reliance" sono tre cose diverse

Qui c'è il dettaglio tecnico più interessante di tutta la storia, e quasi nessuno lo dice.

L'AS18101 che Durov indica è registrato a Reliance Communications Ltd. — il gruppo di Anil Ambani, di fatto insolvente e fuori gioco dal 2018 circa. Non è Reliance Jio. L'AS reale di Reliance Jio Infocomm è un altro: AS55836. E la quota di Meta? È in Jio Platforms, l'entità di Mukesh Ambani. Tre soggetti diversi, due fratelli Ambani che si sono spartiti l'impero a metà anni 2000.

Durov dice genericamente "Reliance", quindi in senso largo non sbaglia. Ma il momento in cui scendi all'ASN preciso, l'accusa punta a un'entità diversa da quella che possiede la rete mobile indiana e da quella in cui Meta ha messo i soldi. È il tipo di imprecisione che, in una vicenda del genere, conta.

Come funziona un BGP hijack (in due minuti)

Il BGP è il protocollo con cui le grandi reti — gli "autonomous system", gli AS — si dicono a vicenda: "per raggiungere questi indirizzi IP, passate da me". Tiene insieme internet. E ha un peccato originale: il BGP classico non ha alcun modo di verificare se chi annuncia una rotta ne ha davvero il diritto. È un sistema basato sulla fiducia. Qualsiasi AS può annunciare qualsiasi prefisso.

Un hijack è esattamente questo: una rete annuncia blocchi di IP che non sono suoi. Se i vicini non filtrano quell'annuncio, l'informazione falsa si propaga nelle tabelle di routing di mezzo mondo, e il traffico destinato alla vittima viene deviato — o buttato nel nulla, un "blackhole" — verso l'AS che ha mentito, finché qualcuno non se ne accorge e corregge.

Normale:
  utente ──> rete A ──> rete B ──> AS di Telegram ──> Telegram

Hijack:
  un AS canaglia annuncia "i prefissi di Telegram sono miei!"
  utente ──> rete A ──> AS canaglia ──X  (blackhole: il traffico non arriva)

Esiste anche una variante più subdola, il route leak (definito formalmente dalla RFC 7908): un AS ri-propaga rotte oltre il loro scope previsto, violando le policy. Non sempre fa danni vistosi, ma può deviare il traffico su un percorso non voluto — abilitando intercettazione e analisi — e a volte causare sovraccarico o blackhole.

Non è fantascienza: l'Iraq lo ha già fatto a Telegram

Che uno Stato usi il BGP per colpire Telegram non è teoria. È già successo, documentato: in Iraq, alle 13:52 UTC del 5 agosto 2023, il gateway internazionale statale (AS208293) ha iniziato a originare i prefissi IP di Telegram per dirottarne e azzerarne il traffico, su ordine del governo. Lo ha osservato e raccontato Kentik (Doug Madory, una delle voci più autorevoli nel monitoraggio del routing), con dati dai route-collector globali.

Nota la differenza con l'accusa di Durov: in Iraq il blocco colpiva dentro il paese; Durov parla invece di utenti fuori dall'India. Tecnicamente possibile, ma è proprio il genere di affermazione che chiede dati per essere creduta.

Le difese: RPKI/ROV, ASPA, e perché da sole non bastano

• RPKI / ROV. Il titolare di un blocco di IP firma un oggetto crittografico (un ROA, basato su PKI X.509) che dice: "questo prefisso può essere originato solo dall'AS X". I router che fanno Route Origin Validation rifiutano gli annunci che non combaciano. È la difesa principale oggi davvero deployata (circa il 35% delle rotte è RPKI-valid). Limite cruciale: ROV valida solo l'origine, non il percorso. Non vede i route leak né gli hijack costruiti manipolando l'AS_PATH.
• ASPA. Un altro oggetto RPKI che dichiara quali AS sono autorizzati a propagare le rotte di un cliente: dà una base crittografica per beccare i route leak, non solo gli hijack d'origine. Il primo route leak fermato da ASPA è un caso reale del 2023 (documentato da MANRS). È in rapida adozione — ARIN offre il supporto ASPA completo da gennaio 2026.
• Prefix filtering e monitoring. Filtrare gli annunci aiuta, ma è difficile da far rispettare su scala globale; il monitoring degli update BGP è come ti accorgi che qualcosa non va.
• BGPsec, che firmerebbe l'intero percorso, esiste sulla carta ma in produzione non lo usa praticamente nessuno, ancora nel 2026.

Morale: le difese ci sono e funzionano, ma sono attivate a metà. Il BGP resta strutturalmente fragile, per come è nato.

E la storia di Meta?

La terza affermazione di Durov — "Reliance is partially owned by Meta", incorniciata come guerra commerciale tra WhatsApp e Telegram — è quella che regge di meno.

Il fatto verificabile: il 21 aprile 2020 Facebook (oggi Meta) ha investito 5,7 miliardi di dollari (43.574 crore di rupie) in Jio Platforms, diventandone il "largest minority shareholder" con circa il 9,99%. Quota di minoranza, non controllo. E in Jio Platforms — non in Reliance Industries, e di sicuro non in quella Reliance Communications a cui appartiene l'AS18101.

Verdetto

Al di là di chi abbia ragione, la vicenda è una lezione che vale più dell'accusa stessa: dirottare il traffico di un'app non richiede bucarne i server. Basta convincere le reti che la strada giusta passa da te. È un attacco alla fiducia, non al codice. Le difese esistono — RPKI, ASPA — ma sono attivate a metà, ed è proprio per questo che un'accusa così, vera o no, suona perfettamente verosimile. Forse il vero titolo della storia non è "Reliance contro Telegram", ma quanto poco ci vuole a far sparire un pezzo di internet — e quanto poco lo stiamo proteggendo.

Per la cronaca del blocco in sé — l'ordine del governo, l'esame NEET, le date — c'è il blocco di Telegram in India spiegato.

Fonti: post di Pavel Durov su X (@durov, 16/6/2026); CryptoTimes e BusinessToday sulla reazione di Durov; bgp.tools — AS18101 per la titolarità dell'ASN; Meta/Facebook newsroom per l'investimento in Jio (2020); Kentik — Doug Madory per il precedente iracheno (2023); Cloudflare e MANRS per il funzionamento di hijack e difese; RFC 7908 (route leak), 6482 (ROA) e 9582 (profilo ROA aggiornato). L'accusa di hijack non risulta confermata da monitor BGP indipendenti alla data di pubblicazione.