Alfonso Maruccia

Cerf: per Internet in arrivo tempi difficili

Presto la sicurezza delle connessioni e persino il normale funzionamento della rete delle reti saranno questioni problematiche. Da affrontare di petto: appello per il passaggio a IPv6 e SSL

Qual è il nemico più pericoloso della futura Internet delle cose? Internet stessa, risponde Vint Cerf. Il celebrato "papà" del protocollo TCP/IP torna a lanciare il suo appello per il passaggio di istituzioni e business di rete al sistema di indirizzamento di IPv6. Mancano oramai pochi mesi all'esaurimento degli spazi di indirizzi IP assegnabili ai dispositivi connessi in rete, e Cerf prevede inciampi nel normale funzionamento di Internet visto il ritardo con cui è stato messo in cantiere il massiccio switch tecnologico.

L'adozione di IPv6 "deve prendere piede o Internet smetterà di crescere o non potrà più crescere", dice Cerf parlando a beneficio del gruppo UK non-profit 6UK. "Le aziende devono capire che si tratta di un infrastruttura su cui fanno affidamento e che deve cambiare affinché esse possano continuare a crescere o a farci affidamento", ha continuato Cerf, perché "senza uno spazio di indirizzamento" non ci sarà modo di connettere dispositivi alla rete delle reti.

Lo switch da IPv4 a IPv6 non è tanto "un lavoro imponente" quanto piuttosto "meticoloso" da portare a termine, dice Cerf, e il problema è esacerbato dal fatto che i due protocolli sono diversi. A causa di questa diversità e del comportamento di chi ha cominciato in ritardo a passare a IPv6 (o addirittura non ha nemmeno cominciato), prevede il tecnologo, presto il normale funzionamento di Internet diventerà "irregolare".
Quando il numero di servizi, business, provider e aziende che adotta IPv6 sarà aumentato oltre i livelli di guardia, dice Cerf, questa incompatibilità sarà palese: anche se Internet non cesserà di funzionar, e si potrà sperimentare una difficoltà crescente nell'accesso alle risorse telematiche. "C'è del lavoro da fare" e va fatto adesso, dice Cerf.

Altrettanto importante, anche se per motivazioni differenti, risulta il passaggio dalle connessioni HTTP standard a quelle cifrate su HTTPS. Il recente trambusto scatenato dall'addon ruba-cookie Firesheep ha ben evidenziato la necessità di mettere in sicurezza le connessioni web tra client e server remoto, ma il fatto - rivelato da AccessNow - che sui 100 siti web più popolari soltanto uno (PayPal) usi correttamente il sistema di comunicazione cifrata con algoritmo SSL lascia presagire una transizione ancora più lunga e problematica, rispetto al pur storico passaggio da IPv4 a IPv6.

Alfonso Maruccia
Notizie collegate
  • Digital LifeLa Internet delle cose e i calzini di CerfUn nuovo studio evidenzia le magnifiche sorti dell'ubiquitous computing e le meraviglie del mondo interconnesso che sta per venire. I rischi per la privacy e gli utenti? Materia ancora da esplorare
  • TecnologiaIPv4, Internet al bivio?Siamo alla fase finale della distribuzione degli indirizzi IP a 32 bit, avverte NRO. Gli indirizzi IPv4 si esauriranno prima del previsto. Ma i livelli di adozione di IPv6 sono adeguati
  • TecnologiaIPv4, restituiti milioni di indirizziIl Registry statunitense si vede restituire un intero blocco di indirizzi IP. Il 99% degli IP era inutilizzato, e ora il conto alla rovescia per l'esaurimento delle risorse IPv4 si sposta indietro di un mese
  • SicurezzaFiresheep, una pecora nera lo fermeràRilasciato un nuovo add-on per Firefox pensato per contrastare il "ruba-cookie" distribuito pochi giorni or sono. Nel mentre Microsoft pensa a implementare la connessione protetta per la sua webmail
26 Commenti alla Notizia Cerf: per Internet in arrivo tempi difficili
Ordina
  • Ummm vorrei tanto capire come faranno i fornitori di router ad informare, a tutti coloro che hanno acquistato un loro prodotto, ad aggiornare il firmware.
    Inoltre mi chiedo Telecom che farà? Con tutti quei trabiccoli di router che ha in giro... Farà una campagna di richiamo?

    Mah
  • - Scritto da: fox82i
    > Ummm vorrei tanto capire come faranno i fornitori
    > di router ad informare, a tutti coloro che hanno
    > acquistato un loro prodotto, ad aggiornare il
    > firmware.
    > Inoltre mi chiedo Telecom che farà? Con tutti
    > quei trabiccoli di router che ha in giro... Farà
    > una campagna di
    > richiamo?
    >
    > Mah

    Io uso prodotti Apple, quindi non mi pongo il problema.
    ruppolo
    33147
  • - Scritto da: ruppolo
    > - Scritto da: fox82i
    > > Ummm vorrei tanto capire come faranno i
    > fornitori
    > > di router ad informare, a tutti coloro che hanno
    > > acquistato un loro prodotto, ad aggiornare il
    > > firmware.
    > > Inoltre mi chiedo Telecom che farà? Con tutti
    > > quei trabiccoli di router che ha in giro... Farà
    > > una campagna di
    > > richiamo?
    > >
    > > Mah
    >
    > Io uso prodotti Apple, quindi non mi pongo il
    > problema.

    Questo è il top delle risposte sballate, fuori tema e allucinate di Ruppolo. Complimenti per la nuova vetta raggiunta! E grazie delle risate!
    Funz
    12989
  • - Scritto da: Funz
    > - Scritto da: ruppolo
    > > - Scritto da: fox82i
    > > > Ummm vorrei tanto capire come faranno i
    > > fornitori
    > > > di router ad informare, a tutti coloro che
    > hanno
    > > > acquistato un loro prodotto, ad aggiornare il
    > > > firmware.
    > > > Inoltre mi chiedo Telecom che farà? Con tutti
    > > > quei trabiccoli di router che ha in giro...
    > Farà
    > > > una campagna di
    > > > richiamo?
    > > >
    > > > Mah
    > >
    > > Io uso prodotti Apple, quindi non mi pongo il
    > > problema.
    >
    > Questo è il top delle risposte sballate, fuori
    > tema e allucinate di Ruppolo. Complimenti per la
    > nuova vetta raggiunta! E grazie delle
    > risate!

    Fuori tema? Non stiamo parlando di IPv6?
    I router Apple hanno il supporto completo a IPv6 da anni.
    ruppolo
    33147
  • - Scritto da: ruppolo
    > Fuori tema? Non stiamo parlando di IPv6?

    no (vedi risposta sotto)

    > I router Apple hanno il supporto completo a IPv6
    > da
    > anni.
  • QUindi tu hai obbligato il tuo provider a installare un router apple (da quando in qua fa router?) per non avere il problema.
    Tu hai un differente tipo di problema, che ti ha portato al vertice della comicità involontaria.
    non+autenticato
  • Scusa, ma hai capito di cosa si sta parlando????
    non+autenticato
  • - Scritto da: Flavio
    > Scusa, ma hai capito di cosa si sta parlando????

    Certo, di IPv6. E io ho detto che non mi pongo problemi, visto che utilizzo prodotti Apple.
    O forse se non specifico che i router Apple Airport Extreme, Airport Express e Time Capsule supportano pienamente IPv6 da anni, tu non comprendi?
    ruppolo
    33147
  • - Scritto da: ruppolo
    > - Scritto da: Flavio
    > > Scusa, ma hai capito di cosa si sta parlando????
    >
    > Certo, di IPv6.

    sbagliato, si stava parlando di produttori, comunicazioni, aggiornamenti di firmware e procedura di telecom per i suoi router

    > E io ho detto che non mi pongo
    > problemi, visto che utilizzo prodotti
    > Apple.

    quindi sei OT

    > O forse se non specifico che i router Apple
    > Airport Extreme, Airport Express e Time Capsule
    > supportano pienamente IPv6 da anni, tu non
    > comprendi?

    Io credo che comprenda benissimo, ti ha fatto notare che sei OT, non che il tuo hw apple è solo IPv4
  • - Scritto da: ruppolo
    > - Scritto da: Flavio
    > > Scusa, ma hai capito di cosa si sta parlando????
    >
    > Certo, di IPv6. E io ho detto che non mi pongo
    > problemi, visto che utilizzo prodotti
    > Apple.
    > O forse se non specifico che i router Apple
    > Airport Extreme, Airport Express e Time Capsule
    > supportano pienamente IPv6 da anni, tu non
    > comprendi?

    insomma: ogni scusa è buona per fare un po' di astroturfing. Rotola dal ridere
    Ti sei dimenticato di dire che anche Linux (e la maggioranza dei router che girano con Linux) supporta IPV6 da anni.
    Ma sarebbe pretendere troppa onestà intellettuale (da un macaco? intellettuale? Rotola dal ridere)
    Funz
    12989
  • - Scritto da: ruppolo
    > Io uso prodotti Apple, quindi non mi pongo il
    > problema.

    E quindi?
    Io NON uso prodotti Apple, e comunque non mi pongo il problema.
  • Ebbene, la mia testimonianza su una banca italiana è questa. Non ho potuto sperimentare personalmente, ma da quello che ho visto mi sono fatto un'idea

    Le banche del gruppo Intesa Sanpaolo hanno un sito standard in cui la form di login viene presentata su HTTP IN CHIARO!!! Poi ovviamente passa ad HTTPS...

    Ebbene se mi date un qualcosina di soldi, i dovuti e doverosi manuali e un po' di infrastrutture so come mettervi su un tool che grazie a questo strapalese baco permette di sniffare tutto il traffico dell'utente che non specifica dapprincipio "HTTPS", e successivamente cattura le credenziali OKey per ESEGUIRE una operazione a piacimento dell'attacker.

    Il trucco? Semplice: l'HTML della form di login non è nè crittografato (perchè non è un segreto che per loggarsi ci vogliono 3 codici), ma nemmeno AUTENTICATO. La domanda è: DOVE verranno inviati i dati? Un man-in-the-middle attack fatto bene permette di fare traffic hijacking facendo postare la form verso un altro URL forgiato apposta o comunque verso lo stesso DNS ma in chiaro (quindi se la connessione era stata compromessa lo sarà ulteriormente).

    Meditate gente, meditate...

    PS questo post non intende in alcun modo promuovere o screditare alcuna banca, ma solo fare cronaca
  • Non e' l'unica banca ad agire cosi', ce ne sono altre.

    Su alcune almeno e' supportato (anche se deve essere esplicitato dall'utente)l'accesso via ssl alla pagina di login.

    In altri casi il servizio e' gestito da terzi e non direttamente dalla banca quindi accedendo in ssl il certificato NON corrisponde all'indirizzo di accesso della propria banca !!!
    non+autenticato
  • > Un man-in-the-middle attack fatto
    > bene permette di fare traffic hijacking facendo

    hai detto niente..
    man-in-the-middle da remoto e traffic hijacking non sono certo tecniche semplici da realizzare, neppure per i più bravi professionisti.
    Diciamo che se tu fossi in una situazione mitm comunque ci sarebbero ben poche misure di sicurezza non "bucabili", questo non toglie che tutti i siti con una certa criticità debbano essere realizzati con la massima attenzione
    non+autenticato
  • A proposito di banche, mi sono accorto ora che Fineco reindirizza il suo indirizzo all'http se viene richiesto in https... e l'https non appare neppure dopo aver effettuato il login.......Sorpresa
  • Va bene per i collegamenti in Banca. Va bene per collegarmi alla mia casella di posta. Va bene anche per la fase di autenticazione di qualunque blog, forum et similia.
    Ma la stragrande maggioranza dei siti internet sono "pubblici": perché Google Search o Google Maps dovrebbero sprecare tempo di calcolo ed andare in Https? O Pagine bianche? O la vetrina online di un qualunque negozio?
    Inoltre da una vita telefono dal telefono fisso di casa, ben conscio che chiunque può passare davanti all'armadio giù in strada, spelare due fili e ascoltarsi la mia conversazione, anzi addirittura fare telefonate facendole addebitare a me. Se è una persona onesta sa che farlo è un reato penale; se è un mascalzone di prima categoria non sarà nemmeno l'https a fermarlo (chi ha detto keylogger?).
    non+autenticato
  • Mi pare non si sia parlato di Maps & Co.

    Io aggiungerei invece che anche una qualsiasi contact form debba essere cifrata, anche sui blog. Se io lascio il mio indirizzo mail in maniera che sia visibile solo all'admin, non vorrei farlo girare in chiaro.

    Oggi c'è Firesheep, domani qualcuno avrà la bell'idea di rastrellare indirizzi mail dalle connessioni non protette (hai notato che ReCaptcha mail è SSL?)
  • Condivido in toto, anch'io nel mio piccolo ho messo un form in SSL
    non+autenticato
  • A questo mondo l'adozione di nuove tecnologie o protocolli di comunicazione che comporti investimenti non indifferenti avviene solo ed esclusivamente quando non se ne può più fare a meno.

    Le reti IPv6 comportano non solo l'aggiornamento di tutti i vecchi S.O. che non lo implementavano (e soprattutto in ambito aziendale vi sono ancora PC con sopra Windows 95) ma anche di alcune infrastrutture di rete (router e firewall in primis) e l'impiego di personale che sappia configurarle correttamente. Tutto questo ha un costo... finché possono arrancare usando il NAT perché dovrebbero farlo ?

    D'altro canto l'impiego delle connessioni protette SSL comporta un overhead computazionale che moltiplicato per le migliaia (o milioni) di connessioni al secondo di siti quali Facebook ha un impatto economico non indifferente. Perché dovrebbero farlo ? Capisco una banca o un servizio di transazioni monetarie... ma se ad un utente il collega o il vicino di casa connesso sulla stessa rete wi-fi ruba l'account di FB sai a quanti può fregare ?
    non+autenticato
  • Mah
    se i provider non gestiscono l'IPV6 non mi posso collegare con IPV6!
    Il problema non sono le reti interne che potrebbero continuare a funzionare in IPV4 in eterno, ma le connessioni internet.
    Se ho il router che mi gestisce l'IPV6 in WAN ma dall'altr parte mi continuano ad assegnare un IPV4 il singolo che può fare??
    non+autenticato
  • - Scritto da: Flavio
    > Mah
    > se i provider non gestiscono l'IPV6 non mi posso
    > collegare con
    > IPV6!
    Falso!
    Se hai un ipv4 pubblico hai "automaticamente " una rete /48 di indirizzi ipv6 piubblici da te routabili!
    E se invece sei dietro un NAT puoi avere lostesso un ipv6 pubblico routabile via tunnel ISATAP o TEREDO o via tunnelbroker!
    Anche se il tuo isp è solo ipv4!

    > Il problema non sono le reti interne che
    > potrebbero continuare a funzionare in IPV4 in
    > eterno, ma le connessioni
    > internet.
    > Se ho il router che mi gestisce l'IPV6 in WAN ma
    > dall'altr parte mi continuano ad assegnare un
    > IPV4 il singolo che può
    > fare??
    Vedi sopra!
    non+autenticato
  • L' adozione di IPV6 è più che altro problematico a livello di utenza/client

    quanto ad SSL, se si tratta di problemi tipo firesheep, costerebbe molto meno costruire browser + robusti e sicuri.
  • - Scritto da: Alessandrox
    > L' adozione di IPV6 è più che altro problematico
    > a livello di
    > utenza/client
    >
    Al contrario è e sarà un problema ISP E service provider che per lungo (anzi) lunghissimo tempo dovranno far coesistere una enormità di sistemi e routers dual homed e dual stack.
    In modo che la utenza possa raggiungere trasparentemente ambedue le classi di sistemi.
    L'utenza ha già a disposizione sistemi operativi (win,Mac, linux ecc.) Che supportano il dual stavo in modo perfettamente "retrocompatibile".
    Č la infrastruttura degli isp a essere in largo ritardo.

    > quanto ad SSL, se si tratta di problemi tipo
    > firesheep, costerebbe molto meno costruire
    > browser + robusti e
    > sicuri.
    non+autenticato
  • Ci sono alcune cose che non sono chiare a nessuno di voi.

    La prima è l'adozione di IPv6: prima che esso soppianti IPv4 ci sarà una coesistenza di lunga durata, ed oggi ciascuno di noi può avere un IPv6 tramite un tunnel broker a meno che non sia nattato dal provider, come Fastweb e gli ISP mobili. Quindi anche le macchine Win95 avranno molto tempo.
    Il guaio poi è che sarebbero proprio gli ISP mobili (quelli delle "chiavette") a doversi IMMEDIATAMENTE munire di v6. Lo so perchè anche io ho sbattuto la testa col problema di sincronizzare un PDA col PC di casa via UMTS: roba impossibile se a casa siete nattati e/o non avete IPv6

    Il secondo è l'adozione di SSL in ambito hosting: non entro troppo nel dettaglio, ma sappiate che se in HTTP normale voi su un solo IP potete hostare infiniti siti, con HTTPS ogni IP, a meno di non rifare il certificato ogni volta, è legato a UNO E UN SOLO SITO. Dunque un hosting provider ha bisogno di indirizzi per dare HTTPS al cliente, e gli indirizzi sono risorsa rara. Con V6 non vi viene dato un IP ma una sottorete intera, per cui 2^64 siti SSL per ogni sottorete mi sembra una quantità comunque esagerata pur non essendo "infinita"

    Sulle prestazioni teniamo solo conto che il vero "pericolo" è lo slashdot effect. Ma qui per una home page di un sito pubblico "slashdottabile" è sufficiente usare HTTP classico. I cookie li mandiamo su canali sicuri... Però l'osservazione calza ugualmente!
  • - Scritto da: djechelon
    > Ci sono alcune cose che non sono chiare a nessuno
    > di
    > voi.

    > Il secondo è l'adozione di SSL in ambito hosting:
    > non entro troppo nel dettaglio, ma sappiate che
    > se in HTTP normale voi su un solo IP potete
    > hostare infiniti siti, con HTTPS ogni IP, a meno
    > di non rifare il certificato ogni volta, è legato
    > a UNO E UN SOLO SITO. Dunque un hosting provider
    > ha bisogno di indirizzi per dare HTTPS al
    > cliente, e gli indirizzi sono risorsa rara. Con
    > V6 non vi viene dato un IP ma una sottorete
    > intera, per cui 2^64 siti SSL per ogni sottorete
    > mi sembra una quantità comunque esagerata pur non
    > essendo
    > "infinita"
    >

    Scusa ma non si capisce niente di quello che volevi dire, sei sicuro di non avere tu le idee confuse? Confondi l'URL di un sito con l'indirizzo fisico. Su un solo indirizzo fisico puoi ospitare quanti siti HTTP e HTTPS vuoi. E' ovvio che i certificati SSL "certificano" l'URL e te ne serviranno uno per ogni sito HTTPS. Di quali indirizzi avrebbe bisogno il provider?
    non+autenticato
  • > ... Su un solo indirizzo fisico
    > puoi ospitare quanti siti HTTP e HTTPS vuoi. E'
    > ovvio che i certificati SSL "certificano" l'URL e
    > te ne serviranno uno per ogni sito HTTPS. Di
    > quali indirizzi avrebbe bisogno il
    > provider?

    Sbagli, ogni virtual host HTTPS ha bisogno di un indirizzo IP diverso.
    non+autenticato