NEWS
TECHNICAL FOCUS
La pubblicazione tecnica di IPJ [Summer2021 issue]
I focus su questo numero: il nuovo protocollo di routing (già accennato nel numero di settembre dello scorso anno),
ossia il Routing in Fat Trees (RIFT); e poi il Newtork Functions Virtualization (NFV) come un nuovo insieme di standard sviluppato dall’ European Telecommunication Standard Institute (ETSI).
Routing in Fat Trees
Nuovo protocollo definito dall’ Internet Engineering Task Force (IETF), è nato come alternativa al consolidato BGP, Border Gateway Protocol.
RIFT è ottimizzato per network di grandi dimensioni che hanno topologie di rete fortemente strutturate come un albero grasso.
Viene tipicamente usato negli apparati underlay dei data center per la sua scalabilità e velocità di convergenza, ma anche per altri motivi quali la semplicità d’uso e per essere anisotropico, ossia link-state (basato sullo stato del collegamento) nella frontiera nord e distance-vector (basato sul vettore delle distanze) nella frontiera sud.
Può essere eseguito anche su macchine server (Routing on The Host), e viene offerto sia in implementazione open-source che con licenza commerciale.
L’articolo di Bruno Rijsman si focalizza sull’innovazione più interessante di RIFT, ossia l’aggregazione e disaggregrazione automatica che riduce la dimensione della tabella di routing. RIFT si può usare nelle topologie di rete dove ha senso parlare di “direzioni nord-sud”, tecnicismo che permette di dividere i nodi, switches, router o host, in livelli, includendo topologie ad “albero grasso” tipiche dei data center.
Se per molti aspetti RIFT è simile al protocollo link-state Intermediate System-to-Intermediate System (IS-IS), la tabella di routing più piccola e una velocità di convergenza più elevata permette di dire che il Routing in Fat Trees può rappresentare il protocollo prossimo più idoneo in ambienti strutturati quali i corporate o i global network.
Newtork Functions Virtualization
Il Newtork Functions Virtualization (NFV) nasce originariamente dalla discussione tra i maggiori operatori e carrier network sul come poter aumentare le operazioni di network in un epoca di alti volumi di traffico multimediale.
Questa discussione risulta pubblicata già nel 2012 come white paper all’interno del European Telecommunication Standard Institute (ETSI).
Nel white paper si focalizzavano gli obiettivi del NFV, facendo leva sugli standard della tecnologia di virtualizzazione nel mondo IT per consolidare i molti tipi diversi tipi di network equipment in un nuovo standard per alti volumi che potrebbe essere utilizzato sia nei data center che per gli utenti finali on premise.
La necessità di questo nuovo approccio nasce dal fatto che nei network coesistono diversi varietà di hardware appliance proprietari, con conseguenze negative quali la rapida obsolescenza e di fine vita degli apparati, il maggior spazio fisico necessario, e la difficoltà per gli skills tecnici necessari alla loro gestione, integrazione e deployment.
Il Newtork Functions Virtualization è un approccio che permette di staccarsi da questa visione per proporre l’utilizzo di un piccolo numero di piattaforme hardware standard grazie alla tecnologia di virtualizzazione, mantenendo le funzioni di network necessarie.
Con la crescente domanda dovuta al servizi wireless 5G e ai servizi di cloud, cosi pure per i grandi network di corporate private, NFV sta diventando una tecnologia di uso sempre più ampio.
DNSSEC vs HTTPS
La pubblicazione tecnica di IPJ [Spring2021 issue]
Nel numero di IPJ di Marzo 2021: come sta evolvendo il servizio DNS.
L’articolo di Geoff Huston offre lo spunto per mettere a confronto due protocolli alternativi come soluzione al problema della sicurezza del servizio DNS così com’è stato concepito: DNSSEC e HTTPS.
DNSSEC
La domanda che ci dobbiamo porre è molto semplice: ci dobbiamo fidare di quello che il DNS (Domain Name System) ci dice ?
La risposta è no.
Il motivo va ricercato nella struttura del servizio concepito come una sorta di elenco telefonico di Internet: indica ai computer dove inviare e recuperare le informazioni. Purtroppo, accetta anche qualsiasi indirizzo gli venga dato, e senza fare domande.
Esiste dunque un problema legato alla attendibilità delle risposte alle queries dei DNS resolver verso i name server di zona. Nel settembre del 2014 i ricercatori della CMU (Carnegie Mellon University) scoprirono che delle email che si presumeva fossero state inviate tramite i server di Yahoo!, Hotmail e Gmail, passavano invece attraverso server di posta non autorizzati.
Gli autori degli attacchi avevano sfruttato questa vulnerabilità nel DNS legata al fatto che esso non controlla le credenziali prima di accettare una risposta.
In breve, il servizio di DNS è visto come un palese canale di controllo dove è difficile distinguere una risposta “bugiarda” da una genuina.
La soluzione a questo è un protocollo denominato DNSSEC (DNS Security), che aggiunge un livello di fiducia al DNS fornendo un servizio di autenticazione.
Questo meccanismo di autenticazione prende forma aggiungendo una firma digitale alle risposte dei DNS.
L’idea è che attraverso una firma digitale in allegato ad una risposta DNS il ricevente si assicura che l’informazione veicolata dalla risposta è aggiornata, autentica, non alterata ne manipolata, e non ripudiabile.
DNSSEC ci aiuta a prevenire attacchi come il DNS cache poisoning (modifica della cache dei name server per reindirizzare le risposte verso altri server) e il DNS spoofing (attacco di tipo “man in the middle” dove un attaccante si interpone tra il DNS e il ricevente per dirottare le richieste verso altri server).
DNSSEC non protegge i server DNS, ma solo i dati scambiati tra name server di zona configurati con DNSSEC (vedi figura), non prevedendo tuttavia privacy per i dati in memoria.
Per maggiori dettagli tecnici relativi al suo funzionamento si veda la pagina dedicata su Cloudflare
Attualmente circa il 25% degli utenti Internet del mondo non raggiunge un servizio DNS senza che questi abbiano una firma DNSSEC di validazione.
La percentuale, pur se triplicata rispetto il 2014, non rispecchia il numero di server DNS di zona configurati con DNSSEC, un numero vergognosamente basso.
Per capirci, i primi 25 siti visitati al mondo secondo Alexa nessuno di questi ha il proprio dominio gestito da un server di zona autenticato DNSSEC. Tra tutti i domini con estensione .com, .org, e .net di secondo livello solo la percentuale compresa tra lo 0,75% e l’1,0% sono firmati DNSSEC.
Le cause del problema legato al suo poco utilizzo sono da ricercare nella complessità e nella relativa lentezza che le validazioni attraverso firme digitale tra server di zona comportano.
A livello di protocolli comunicativi il TLS /SSL offre una soluzione che è più veloce, semplice e robusta rispetto alle procedure del DNSSEC, facendo di HTTPS un’alternativa altrettanto valida e sicura nel garantire l’affidabilità del sito visitato.
HTTPS
HyperText Transfer Protocol Secure (HTTPS) è la versione sicura del protocollo HTTP, che è il protocollo principale usato per lo scambio di dati tra un web browser e un sito web.
Tecnicamente è il protocollo HTTP che viene cifrato attraverso l’uso del protocollo TLS/SSL (Transport Layer Security/Secure Sockets Layer).
Questa operazione serve a rendere sicura la comunicazione tra due parti e inoltre, attraverso la trasmissione dei certificati TLS/SSL, serve a verificare che quel particolare provider è quello che dichiara di essere.
Questo fatto è particolarmente importante quando gli utenti del sito debbono trasmettere dati sensibili, ad esempio per accedere ad account bancari, servizi email, assicurativi o di pubblica amministrazione.
Il protocollo è chiamato Transport Layer Security (TLS), ed è l’evoluzione dell’originale Secure Sockets Layer (SSL), superato per i tanti problemi di affidabilità.
TLS/SSL usa un algoritmo di cifratura a chiave asimmetrica composto da due diverse chiavi:
una chiave privata: controllata dal proprietario del sito web, e tenuta privatamente. Questa chiave è presente sul sito web ed è usata per decifrare la comunicazione cifrata con la chiave pubblica;
una chiave pubblica: disponibile a chiunque voglia interagire con il server in modo sicuro, e usata per cifrare le informazioni che possono essere decifrate solo dalla rispettiva chiave privata.
Quando un utente si collega ad una pagina web questa spedisce oltre le informazioni della pagina anche il certificato TLS/SSL che contiene la chiave pubblica necessaria per iniziare la sessione in modo sicuro.
I due computers, client e server, danno poi inizio ad un processo chiamato TLS/SSL handshake, che è una serie di comunicazioni “back-and-forth” (“avanti-indietro”) che stabiliscono una comunicazione sicura.
A differenza del traffico HTTP plain-text, il traffico HTTPS è cifrato, e se i pacchetti venissero sniffati o intercettati apparirebbero come una serie di caratteri senza senso.
Diamo un esempio:
prima della cifratura (plain text- HTTP):
This is a string of text that is completely readable
dopo la cifratura (HTTPS):
ITM0IRyiEhVpa6VnKyExMiEgNveroyWBPlgGyfkflYjDaaFf/Kn3bo3OfghBPDWo6AfSHlNtL8N7ITEwIXc1gU5X73xMsJormzzXlwOyrCs+9XCPk63Y+z0=
Per un analisi più approfondita sul meccanismo che regola l’SSL/TLS handshake si veda la pagina dedicata su Cloudflare.
L’utilizzo di DNSSEC non viene favorito da vantaggi economici per i provider che propongono il servizio: la validazione è un processo inefficiente e l’inefficienza è incrementata da un una struttura che pone al client DNS, e non al server, l’onere di questa operazione.
L’end-user non può validare perchè ogni validazione comporterebbe ulteriori DNS queries per costruire la catena di validazioni, con ulteriori ritardi in termini di tempo che renderebbero inaccettabili le aspettative dell’utente.
Un altro aspetto importante da tener presente quando si studia un protocollo come il DNS è legato alla privacy.
Ogni persona, infatti, interroga un DSN.
Dato che Internet è fondata da noi utenti, allora l’attività di noi utenti in Internet è di fondamentale interesse per quei soggetti che vendono servizi e prodotti a noi utenti.
Dato che i cybercrimini sono in aumento vertiginoso negli ultimi anni, i criminali o i comportamenti abusivi su Internet sono di fondamentale interesse per quelle agenzie che hanno lo scopo di monitorare tali comportamenti.
Dato che su Internet abbiamo come gran parte degli individui scelgono di vivere la propria vita, perchè e con quali altre persone comunicano, abbiamo imparato quanto questo sia di fondamentale interesse per i governi.
Ogni transazione su Internet inizia con una query DNS, e la cosa peggiore è che il DNS è un servizio inequivocabilmente “chiaccherone”.
Tutte queste informazioni sono raccolte, analizzate, profilate, replicate e scambiate tra tutti i DNS.
Alla luce delle problematiche descritte precedentemente appare anacronistico che queries e risposte siano in chiaro.
Come, dunque, aumentare il livello della privacy ?
Una generica risposta può essere l’uso di un canale comunicativo cifrato. Come il telnet è stato soppiantato dal più sicuro ssh, anche per il DNS può valere lo stesso approccio.
DNS over TLS over TCP (DoT) è un nuovo meccanismo di risoluzioni di nomi basato su un protocollo HTTP cifrato attraverso il protocollo TLS.
Lo sforzo di implementare il TLS over UDP si è scontrato con il problema di gestire un payload pesante associato alle sessioni stabilite dal processo. Di qui la necessità di usare il TCP.
Un’altra soluzione è l’utilizzo del protocollo DNS over HTTPS (DoH). Qui le richieste DNS appaiono come traffico su porta TCP/443, delegando il browser a richiedere il servizio.
Questo evita di specificare nella configurazione di rete gli indirizzi IP dedicati ai DNS resolver, ma permetterebbe a società come Google, che distribuisce Chrome come web-client, una posizione di forza nel caso decidesse di rendere questo nuovo protocollo un servizio a pagamento.
Quale futuro attende il DNS?
Le pressioni per una sua evoluzione sono più fondamentali delle pressioni per l’evoluzione di Internet stesso.
E’ probabile che la gestione attraverso l’intervento dell’uomo, lo “human-use DNS”, sia sostituito da un codice di programmazione per il comando ed il controllo di sistemi automatici DNS altamente distribuiti.
Questo non vorrà dire che l’intervento dell’uomo nella gestione del DNS sparirà, ma che per il futuro ci sarà meno spazio per il servizio DNS come lo conosciamo oggi.
Lo stesso potrà accadere per i nomi di dominio, in un futuro dove ci sarà più spazio per una loro forma effimera piuttosto che persistente e di proprietà individuale come ora.