Red Hot Cyber
La cybersecurity è condivisione.
Riconosci il rischio, combattilo, condividi le tue esperienze ed
incentiva gli altri a fare meglio di te.
Menu
La cybersecurity è condivisione.
Riconosci il rischio, combattilo, condividi le tue esperienze ed
incentiva gli altri a fare meglio di te.
Redazione RHC : 8 Luglio 2021 08:00
Ne avevamo parlato di recente, con un breve articolo sul Google QUIC protocol (acronimo di Quick UDP Internet Connections), di come Google voglia con questo nuovo protocollo internet, sostituire il vecchio TCP, non più adeguato e sicuro per i tempi moderni.
Siccome l’argomento ha destato molto interesse su Red Hot Cyber, cerchiamo di approfondire il tema con un articolo mirato che possa farci comprendere questo nuovo protocollo come funzioni, partendo dai requisiti di progettazione.
Google QUIC protocol è un protocollo di rete sperimentale a livello di trasporto originariamente progettato da Google. L’obiettivo generale è quello di ridurre la latenza rispetto a quella dell’attuale TCP.
Supporta Red Hot Cyber attraverso
Sebbene QUIC sia in gran parte invisibile agli utenti finali se non attraverso prestazioni migliorate, ha anche un sottile impatto sul modo in cui le reti vengono gestite, sulla riservatezza delle connessioni e sull’evoluzione futura. Di conseguenza, è importante che gli architetti e gli amministratori di rete comprendano questi impatti e si preparino ad essi.
Oggi tutti quanti noi vogliamo che ogni applicazioni si carici istantaneamente e vogliamo che sia sicura. Sebbene lo standard HTTP Secure (o HTTPS) si dimostri un alleato affidabile nella protezione della privacy degli utenti, questo registra un rallentamento “biblico” dei tempi di caricamento a causa dell’handshake TLS, insito nello scambio di chiavi e certificati.
Tutte queste cose oggi sono degli ostacoli importanti alla fluidità delle comunicazioni, e in ottica di banda ultra-larga e di 5G, sicuramente è necessario un ammodernamento, non solo delle componenti hardware, ma anche dello stack dei protocolli di rete. Tutti questi problemi, sono stati convertiti in requisiti di implementazione per la progettazione di QUIC.
Il design di QUIC è focalizzato sulla riduzione al minimo della latenza nella fase di configurazione della connessione, sulla protezione dei pacchetti e delle intestazioni con la crittografia e sulla massimizzazione della capacità di QUIC di evolversi.
Mentre TCP è tipicamente implementato nel kernel del sistema operativo, QUIC è tipicamente implementato come parte di un’applicazione, come ad esempio un browser. Ciò consente un rapido ritmo di adozione ed evoluzione futura. E dato l’uso di intestazioni crittografate, ci si aspetta che la mancanza di aggiornamenti non sia un deterrente così grande per l’evoluzione in QUIC come lo era per il TCP.
Detto questo, la rete e gli endpoint cooperano per fornire il servizio più efficiente per l’applicazione, ciascuno con il proprio ruolo. Avere alcune informazioni sull’efficienza delle connessioni può essere utile nella gestione della rete sottostante. Ad esempio, se le connessioni subiscono ritardi eccessivi, ciò può essere un’indicazione di un problema da qualche parte nella rete. O almeno esiste un’opportunità per mettere punto la rete in qualche modo.
Il design di QUIC protocol, mantiene private tutte le informazioni sulle connessioni che trasporta. Ma ha la capacità di esporre i tempi di andata e di ritorno per le connessioni, consentendo alle reti sottostanti di osservare la situazione e la latenza per il traffico trasportato, almeno da un punto di vista statistico. Il cosiddetto “Spin Bit” nell’intestazione QUIC viene utilizzato per trasmettere questi dati.
Il lavoro di standardizzazione per QUIC avviene presso l’Internet Engineering Task Force o IETF, nel gruppo di lavoro QUIC. Il gruppo sta ultimando i dettagli finali del primo standard. Il lavoro del gruppo avviene principalmente sulla mailing list, ma alcune volte all’anno si incontrano di persona per una sessione attiva faccia a faccia.
Questo è un tipico approccio IETF (The Internet Engineering Task Force) agli standard. Il lavoro è completo solo quando i prodotti effettivi funzionano in situazioni diverse e l’uno contro l’altro e la La IETF ha prodotto una serie di protocolli che mirano a un trasporto più veloce e migliore per Internet.
Tuttavia, i protocolli più recenti come DCCP (Datagram Congestion Control Protocol) e SCTP (Stream Control Transmission Protocol) hanno avuto problemi di distribuzione. I middlebox come NAT e firewall, di solito bloccano tutto il traffico che non riconoscono e impongono persino regole a protocolli già noti, portando all’ossificazione della rete.
La scelta di UDP come protocollo di base per QUIC è stata principalmente quella di ottenere una latenza inferiore sia nella configurazione della connessione che nelle fasi di ripristino. Rimaneva la domanda se UDP potesse penetrare in Internet, poiché c’erano problemi con l’utilizzo limitato di UDP nelle reti e l’associazione NAT UDP.
Nel luglio 2015 Google ha presentato le misurazioni mostrando che QUIC ha funzionato per oltre il 92 percento delle connessioni degli utenti Internet ai servizi Google.
Ora andremo a comprendere i vantaggi di QUIC, ovviamente paragonandoli al protocollo TCP che ci servirà da confronto, anche se, nonostante abbia fatto da apripista per l’ideazione di questo ambizioso protocollo di trasporto.
Sin dal principio è stata riposta attenzione sull’aspetto della sicurezza sia durante la fase di concezione che di progettazione di QUIC, come riportato in precedenza. In seguito gli sviluppatori si sono dedicati a uno dei più grandi problemi relativi a TCP: l’header dei pacchetti inviati che compare sotto forma di testo in chiaro e non può essere letto senza aver prima ricevuto l’autorizzazione. Non è quindi una rarità che vengano condotti degli attacchi MITM (man in the middle) e delle manipolazioni dei pacchetti (ad esempio al numero sequenziale). Invece i pacchetti QUIC sono sempre autentificati e per la maggior parte crittografati (payload incluso). Le parti dell’header che non sono crittografate, sono protette grazie all’ autenticazione da parte del destinatario.
Ogni segmento di dati di una connessione QUIC contiene un proprio numero di sequenza, indipendentemente dal fatto che si tratti di un segmento originale o di uno inoltrato. TCP al contrario non è solito fare questa differenza, cosicché un host non è in grado di identificare lo stato di una sequenza. Solamente attraverso l’utilizzo dell’estensione delle marche temporali (o timestamp) anche il TCP permette una tale differenziazione. La marcatura progressiva dei pacchetti è perciò un vantaggio poiché permette una valutazione accurata del Round Trip Time (RTT), ovvero il tempo impiegato per tornare indietro.
Il motivo determinante per il quale QUIC si dimostra migliore di TCP è la connessione significativamente più veloce. Anche senza codifica SSL/TLS, una connessione per mezzo della cosiddetta three-way handshake attraverso il classico protocollo di trasporto prevede più passaggi rispetto alla soluzione proposta da Google, basata su UDP. QUIC avvia una connessione con un singolo pacchetto (due se si tratta di un primo contatto) e comunica tutti i parametri TLS o HTTPS necessari. Nella maggior parte dei casi un client può inviare i dati anche direttamente a un server, anche senza dover dipendere da una risposta, mentre il TCP deve per prima cosa ottenere ed elaborare una conferma del server.
Per identificare una connessione TCP fa affidamento sulle porte TCP e sugli indirizzi IP dei sistemi collegati. Per questo motivo non è possibile che un client comunichi con il server attraverso più porte all’interno di una singola connessione. Il protocollo QUIC risolve la situazione affidandosi a un identificatore di connessione a 64 bit e a vari “stream” per il trasporto di dati all’interno di una connessione. Una connessione QUIC non è quindi collegata a una singola porta (in questo caso una porta UDP), a un indirizzo IP o a un determinato endpoint. I cambi di porta e IP sono possibili come lo sono le connessioni tramite multiplazione.
TCP tenta di inviare i dati con sempre maggiore velocità, il che rappresenta certo un vantaggio per le connessioni di dati veloci, ma che è collegato a un certo tasso di perdita. Se un pacchetto va perduto, viene immediatamente rinviato (TCP Fast Retransmit). Per fare ciò TCP riduce la finestra di coda temporanea, che ha spesso come conseguenza una trasmissione dati a intervalli. Il protocollo QUIC ovvia a questo carico eccessivo grazie al cosiddetto Packet Pacing. Il procedimento fa sì che il tasso di trasmissione venga limitato automaticamente. In questo modo si evita un sovraccarico anche in caso di connessioni non particolarmente buone. Tuttavia questa tecnica non è nuova: alcuni kernel di Linux utilizzano il procedimento anche per il protocollo TCP.
I pacchetti andati perduti non rappresentano un problema significativo con QUIC. Grazie a un sistema di correzione degli errori basato su XOR non è necessario un rinvio dei dati. Questi possono essere ricostruiti in qualunque momento grazie ai pacchetti FEC (Forward Error Correction), ovvero dei backup dei pacchetti originali per gruppi di dati. Tuttavia la correzione degli errori non può funzionare se mancano più pacchetti di un gruppo di dati.
Anche se lo sviluppo del protocollo QUIC ha fatto grandi passi in avanti, specialmente negli ultimi anni, attualmente viene utilizzato solamente a livello sperimentale nei browser Google Chrome e Opera. Di base lo trovate già attivato nel primo e disattivato nel secondo. Gli utenti Opera devono attivare manualmente il protocollo per beneficiare del cosiddetto performance boost. Qui di seguito vi spieghiamo come fare esattamente per attivare e disattivare QUIC in entrambi i web client.
Innanzitutto è necessario aprire il menu di configurazione delle funzioni sperimentali per poter modificare le impostazioni relative al protocollo QUIC all’interno di Chrome. Per farlo inserite il seguente comando nella barra degli indirizzi:
chrome://flags
A questo punto cercate la voce “Experimental QUIC protocol” attraverso la funzione di ricerca, attivabile con la combinazione di tasti [CTRL] + [F]. Se non avete precedentemente modificato le impostazioni di base allora per quanto riguarda il protocollo dovrebbe essere settato su “Default”. La configurazione standard di Chrome prevede che il protocollo QUIC sia già attivo.
Se desiderate disattivare il protocollo scegliete semplicemente “Disabled” e riavviate il browser cliccando su “RELAUNCH NOW” nella finestra a scorrimento che comparirà nella parte inferiore del browser. Chrome verrà chiuso e, una volta riaperto, le nuove impostazioni saranno attive. Se invece volete riattivare il protocollo, procedete allo stesso modo e selezionate “Default” o “Enabled”.
Al fine di dare vita a QUIC, già a partire dal 2013 Google ha integrato il protocollo nei propri server, perciò tra le applicazioni web che permettono il trasporto dati attraverso quello che sarà probabilmente il protocollo del futuro, ci sono diversi servizi di Google. Prima di qualunque altro va menzionato chiaramente il motore di ricerca, da sempre il servizio centrale dell’azienda. Ma tramite il protocollo QUIC è possibile accedere anche al servizio di mappe Google Maps, al social network Google+, al servizio e-mail Google Mail, alla soluzione per l’ufficio Google Docs o al portale video YouTube; l’unico requisito è che l’utente utilizzi il client adatto.
Gli utenti Chrome possono inoltre verificare quali altri offerte web supportano QUIC grazie all’estensione HTTP/2 and SPDY indicator. L’estensione aggiunge un piccolo simbolo a forma di fulmine accanto alla barra degli indirizzi, che si colorerà di verde ogni qual volta vi troviate su di un sito che supporta il protocollo. Posizionando il cursore del mouse sul simbolo, il tooltip vi fornisce il numero di versione.
Fonti
Redazione
Redazione: [email protected]
© Copyright RED HOT CYBER. PIVA 16821691009
