Tag Archives: dnssec

Vint Cerf, IPv6 e IDN

Nonostante le mie rassicurazioni, questo post arriva un po’ in ritardo, e forse anche fuori tempo massimo, dato che Punto Informatico ha già raccontato molto di quello che avrei scritto io. Dovete perdonarmi, ma è appena terminato un week-end di caldo e sole e io l’ho passato ovunque tranne che a casa: se viveste in Inghilterra sapreste cosa vuol dire! 😉

Vint Cerf è l’uomo più elegante dell’ICANN, così me lo avevano descritto e, martedì mattina, ho avuto una mezza conferma, quando, durante la breve visita a Nominet,  ha sfoggiato un abito grigio scuro impeccabile, con gilè e camicia con gemelli.

Segue breve riassunto dell’intervento.

Le maggiori sfide di Internet: IPv6

(PI ne parla in modo abbastanza chiaro qua) Lo spazio di indirizzamento associato a IPv4 si sta esaurendo. Sono 15 anni che si sta esaurendo, ma adesso si sta cominciando a vedere il fondo. Se non ci diamo una mossa, qualcuno potrebbe cominciare a comprare interi range di indirizzi IP al solo scopo di venderli, in un secondo tempo, a prezzi elevati. Se questo dovesse verificarsi, il problema diventerebbe ancor più grande.

Da un punto di vista tecnico non c’è nulla che freni il passaggio a IPv6, alcuni registry sono già pronti, altri lo saranno a breve. Il problema sono gli ISP. Molti non sono ancora pronti al passaggio e preferiscono rimandare il problema piuttosto che investire e risolvere.

La transizione sarà comunque lunga e solo se iniziata per tempo sarà indolore (o quasi). Immaginatevi questo scenario: gli indirizzi IPv4 terminano e nuovi siti (e nuovi ISP) sono costretti ad utilizzare solo IPv6. Si rischia la fragmentazione della rete (fragmentazione fisica).

Le maggiori sfide di Internet: Internationalised Domain Names and gTLD

IDN, cioè la possibilità di registrare un nome di dominio utilizzando caratteri non latini (questo post, in fondo). Nuovi gTLD, cioè la liberalizzazione (o quasi) nella registrazione di nuovi nomi di dominio di primo livello (.it, com, org, etc.). Questo problema ha due aspetti:

  • Sicurezza. Il rischio di phishing aumenta incredibilmente data la quantità di caratteri esistenti.
  • Tecnico. Il carico sui root server aumenterebbe notevolmente. Nella loro configurazione attuale, possono gestire fino a un migliaio di TLD, equivalente a circa tre volte il numero attuale. Se ci fosse un;impennata nel numero di nuovi TLD l’intera infrastruttura potrebbe risentirne.

Il problema più urgente, naturalmente, è quello della sicurezza. È interessante notare che, sebbene l’introduzione di IDN creerebbe diversi problemi, essa è necessaria. Esistono paesi che danno la possibilità agli utenti di utilizzare Internet nella propria lingua. Gli ISP di questi paesi hanno server dedicati alla traduzione delle query per garantire l’interoperabilità con il DNS dell’ICANN.

Sono realtà importanti che non possono essere ignorate e, se il problema non viene risolto, si rischia di andare verso una fragmentazione di Internet (fragmentazione logica).

DNSSEC

Lo sviluppo di DNSSEC è importante, soprattutto alla luce delle recenti vulnerabilità nel DNS. L’ICANN è fortemente influenzato dal governo degli Stati Uniti (volenti o nolenti, questa è la realtà) e difficilmente qualcosa si muoverà sul lato DNSSEC, finché il nuovo governo (indipendentemente da chi vincerà) non si sarà installato (quindi, non prima di Gennaio dell’anno prossimo).

NB: questo non implica un coinvolgimento diretto del Presidente, naturalmente, ma è tutta la macchina decisionale che ruota intorno a Washington che, di fatto, si ferma fino a nuovi ordini.

Censura in Cina

Qualcuno ha chiesto perché Google censura in Cina. Da politico navigato qual è, la sua risposta è stata impeccabile: “preferiamo censurare che noi che far censurare a loro, almeno abbiamo il controllo di quel che succede. Solo la versione .CN è censurata, non quella internazionale. Censuriamo solo l’1% dei siti (vabbé, questa se la poteva risparmiare. se mi censuri la parte alta dei risultati di ricerca è come censurarli tutti)”.

Ha poi concluso ricordando che nessuno dei loro servizi basati in Cina, così le autorità non possono chiedergli i log dei server o i dati personali degli utenti (come fanno i nostri competitor, ha aggiunto…).

Chrome e Google

Spinto da qualche domanda, Vint Cerf ha un po’ parlato di Google Chrome. Niente di particolarmente rilevante.

Non ha detto una parola a proposito del telefonino con Android. A parte che il lancio ufficiale non c’era ancora stato, credo non avesse voglia di imbarcarsi in una raffica di domande senza fine.

Advertisements

Il segreto di Pulcinella

Come previsto, il segreto (che segreto non era da un pezzo) ora e’ totalmente di pubblico dominio.

Una breve ricerca con Google individua gia’ decine di siti (Slashdot compreso) che parlano del non-segreto. Ad esempio, qui.

In pratica, Halvar Flake ha formulato un ipotesi e un ricercatore di Matasano Security ha gentilmente confermato. Tranquilli, ora chiede scusa. In pratica, il super-segreto che era mezzo segreto perche’ molti lo conoscevano, anzi un quarto perche’ chi non lo conosceva dice che uno bravo lo avrebbe capito, anzi un ottavo perche’ quello bravo dice che era troppo facile per lui, non e’ piu’ segreto.

Qui la descrizione dettagliata, di seguito una spiegazione “fatta in casa” per cercare di dare forma ai tecnicismi.

***
Supponiamo che io sono un cattivo e voglio far si’ che tutti gli utenti di un ISP (esempio, Telecom Italia) che visitano il sito di Repubblica.it vengano indirizzati al mio sito (fasullo) di Repubblica. Quello che devo fare e’ incredibilmente semplice:

  1. Interrogo il nameserver di Telecom Italia con “AAAAAA.REPUBBLICA.IT” (suponiamo si chiami NS-TI)
  2. Il sito non e’ nella cache di NS-TI e questo gira la richiesta al nameserver di Repubblica.it (es, VENERE.INET.IT)
  3. VENERE.INET.IT dovrebbe rispondere qualcosa del tipo “sito inesistente” e la risposta sarebbe memorizzata da NS-TI
  4. Fra domanda e risposta c’e’ un breve intervallo di tempo in cui io, cattivo, posso creare una risposta fasulla da spedire a NS-TI
  5. Non c’e’ modo, per NS-TI, di sapere chi ha generato una data risposta, o meglio, un modo c’e’: ogni query contiene un ID generato casualmente che deve essere riprodotto nella risposta
  6. Io, cattivo, non conosco questo ID e posso solo indovinarlo. Le probabilita’ sono molto basse, ma se lo indovino ho convinto NS-TI che la mia risposta fasulla e’ invece quella vera. Quante probabilita’ ho di indovinare? 1/65536 (circa), se gli ID vengono generati casualmente. Molto bassa, ma posso ripetere lo stesso giochino con AAAAAB.REPUBBLICA.IT e cosi’ via finche’ non “c’azzecco”

Supponiamo che, ad un certo punto, riesca a convincere NS-TI che FFFFFF.REPUBBLICA.IT sia io. A che mi serve? Nessuno digitera’ un indirizzo cosi’ stupido. Vero, ma si da il caso che ci sia una piccola regolina nel funzionamento del DNS che mi dice che, insieme alla risposta di FFFFFF.REPUBBLICA.IT, io possa mandare un update per VENERE.INET.IT.

Cosa vuol dire? Che da questo momento in poi, qualunque utente del service provider Telecom Italia che digiti WWW.REPUBBLICA.IT sul suo browser verra’ rediretto al mio sito. Ora immaginate che questo giochino venga fatto con il sito di una banca online.

***

SOLUZIONE
Senza entrare nei dettagli, Dan Kaminski propone di applicare un “source port randomisation”, che vuol dire che io, cattivo, non solo devo indovinare l’ID contenuto nel messaggio ma anche la porta UDP dal quale il messaggio e’ partito.

La comunita’ internet e’ d’accordo che questa e’ una mezza soluzione, perche’ se diminuisce le probabilita’ dell’attacco non lo elimina del tutto:

  • Ho letto da qualche parte che alcuni cache resolver non usano tutte le porte possibili (65535) ma solo un sotto-insieme, rendendo la soluzione meno efficace
  • In altri casi, le porte cambiano in maniera sequenziale (cioe’, se prima ho usato 1025, ora uso 1026 e cosi’ via)

Ma il vero problema e’ che se prima un hacker ci impiegava 10 secondi adesso ci impiega, nel peggiore dei casi, 10*65535 secondi, circa 8 giorni. Cio’ che fa la differenza e’ la mole di traffico che l’attacco genererebbe, che difficilmente non verrebbe notato dai firewall degli ISP.

Se l’attacco, pero’, venisse distribuito in maniera intelligente fra vari ISP e diluito in un periodo di tempo piu’ lungo (ad esempio, qualche mese) potrebbe non essere facilmente rilevabile. Se i tempi vi sembrano lunghi, pensate che, con un simile attacco, avreste la certezza che da qui alla fine dell’anno il sito della vostra banca preferita sara’ hackerato. Speriamo solo “non con il mio ISP.

L’unica soluzione, come ho parlato da qualche parte, e’ DNSSEC, ma ha ancora troppe resistenze di tipo politico.

PS: in ogni caso, ho la vaga sensazione che manchi ancora un tassello… forse, pero’, questa volta mi sbaglio.