L’HTTP/3 è tra noi ed è il momento di chiedersi che impatto avrà sulla cyber security.
Indice degli argomenti
Cosa è HTTP/3
Sì, perché già dal 2019, anche se in forma sperimentale e a rilento, ha iniziato a diffondersi HTTP/3, che dal 2020 può essere abilitato in browser di largo consumo quali Chrome e Firefox. Sebbene non ancora maturo, e soprattutto non ancora diffuso, oggi ormai possiamo dire che HTTP/3, il nuovo protocollo http, è una realtà. Questo, oltre a portare a una serie di considerazioni tecniche, deve essere valutato nell’ambito della cyber security.
Addio TCP, benvenuto QUIC
A livello progettuale, HTTP/3 è un salto quantico rispetto alla precedente versione, il che ovviamente non ci deve stupire: nasce per questa ragione. HTTP/3 migliora il protocollo su più fronti: prestazioni scalabilità e sicurezza. Questo risultato è ottenuto con una lunga serie di accorgimenti tecnici anche se il più evidente, e discusso, è la semplificazione del processo di connessione 3-way handshake del TCP. Tutto, sfruttando in sua vece il protocollo QUIC.
HTTP/3, questione di prestazioni
Una delle principali criticità del HTTP/2, evidente specie negli ultimi anni, cioè quando si è diffuso l’utilizzo di servizi in streaming (non si faccia l’errore di pensare “solo” a Netflix e intrattenimento, ma si considerino, tanto per dire, anche soluzioni di videoconferenza), risiede proprio nell’uso del Transfer Control Protocol, di fatto incapace di gestire la trasmissione di più file, contemporaneamente, su un’unica connessione.
C’è poi il problema intrinseco che il TCP considera tutti i dati come un unico flusso (byte stream). E quindi, se si perde un pacchetto, quelli a seguire vengono messi in attesa fino al suo recupero. HTTP/2 aggira il problema sfruttando il multiplexing, ma di fatto solo operando nell’application layer, con delle conseguenze importanti sia a livello di sicurezza che di prestazioni.
E, a proposito di queste ultime, va detto che il mai-troppo-lodato 3-way handshake pare aver fatto il suo tempo, visto che si tratta di un processo lento e poco efficiente, che può richiedere, da solo, anche più di 200 millisecondi. E così, ecco l’adozione del QUIC per HTTP/3.
HyperText Transfer Protocol, una lenta evoluzione
L’HyperText Transfer Protocol, o http, come sappiamo, è un protocollo di trasferimento nonché una delle colonne portanti del World Wide Web. Si tratta di una tecnologia sviluppata verso la fine degli anni 80, nella versione 0.9, sebbene per vederla davvero in azione si è dovuto attendere il 1991, quando fu ratificata la versione HTTP/1.0.
Di base, l’HTTP è necessario per fare una cosa molto semplice: sulla base di un’architettura client-server, si occupa di fare in modo che il client effettui una richiesta a un web-server, il quale, di solito, gli ritornerà una risposta, consentendo la navigazione web. Il mondo dell’informatica, da quel lontano 1991, è passato dal paleolitico all’età contemporanea, e giocoforza anche l’HTTP, che rimane al momento uno dei pochissimi punti saldi che ci hanno accompagnato in più di trent’anni, si è dovuto adeguare.
E questo è avvenuto con la ratifica di nuove versioni principali: HTTP 1.1 prima (tecnicamente non una versione “principale”, ma ha avuto un impatto notevole nell’evoluzione del protocollo), e quindi HTTP 2 (o HTTP/2), nel 2009. Oggi, ci troviamo ad affrontare la terza evoluzione.
HTTP/3, un parente del UDP: quale cyber?
Il protocollo QUIC (Quick UDP Internet Connections) nasce per opera di Google nel 2012 e, di fatto, rappresenta un’evoluzione dello storico UDP. E siccome, anche in QUIC, non esiste il concetto di connessione, l’eventuale perdita di un pacchetto non inficia tutto il flusso, e quindi la trasmissione, ma solo il byte stream di quello specifico pacchetto.
Le prestazioni, in questo modo, migliorano: Google Cloud Platform ha introdotto QUIC nei load balancer, mostrando una diminuzione dei tempi di caricamento dell’8% a livello medio globale, e fino al 13% in regioni specifiche.
Senza alcun tipo di ottimizzazione, ma solo cambiando protocollo.
L’impatto cyber
Ovviamente, come noto ai più, QUIC si appoggia a livello progettuale al UDP ma si diversifica da questo per molte, importanti, caratteristiche, soprattutto per garantirne la sicurezza. Per esempio, QUIC supporta di default la crittografia tramite TLSvc3, rendendo quindi HTTP/3 un “HTTPS” nativo.
Inoltre, QUIC estende la crittografia alla maggior parte delle informazioni del suo header e al payload, laddove TCP esponeva fin troppi campi. Senza contare che vanta alcune soluzioni di sicurezza figlie di uno studio approfondito degli attacchi più utilizzati negli ultimi anni. Per esempio, QUIC vanta una forma di protezione dai replay attack, perché è in grado di riconoscere copie dei medesimi valori derivati dalle chiavi crittografiche, scartandole a livello del server. Inoltre, grazie a un sistema di validazione degli indirizzi, QUIC limita le possibilità di IP Spoofing.
Un grosso aiuto, insomma, per il mondo della cyber security.
Replay attack: come funziona, quanto può essere pericoloso e come mitigare il rischio
Dubbi sulla sicurezza di HTTP/3
La tecnologia di QUIC, e quindi di HTTP/3, appare dunque solida anche sul versante della sicurezza, ma ci sono delle perplessità, lecite, su alcuni aspetti. Per esempio, in un approfondito studio del 2015, alcuni ricercatori della Georgia Tech dimostrarono che il QUIC poteva essere vittima di un Server Config Replay Attack, le cui conseguenze non sfiorerebbero l’integrità e confidenzialità dei dati, passando invece nel dominio dei Denial of Service.
Con un attacco di questo tipo, infatti, si riuscirebbe a degradare, e di molto, le prestazioni della connessione. A tal proposito, c’è anche chi ipotizza che il QUIC non sia immune dal DDoS, ottenuto tramite un attacco di amplificazione UDP.
È per questa ragione che HTTP/3 integra un sistema di limitazione del traffico e una validazione a breve termine dei token di connessione, che possono rappresentare dei validi metodi di mitigazione.
Il futuro del terzo protocollo http: un percorso lungo e difficile
In realtà, la principale preoccupazione in merito alla sicurezza di HTTP/3, oggi, è relativa alla sua implementazione pratica. Quel processo, cioè, che consentirà, lentamente, di imporre HTTP/3 in modo omogeneo.
Il discorso è che, al momento, sono poche le realtà a supportare appieno HTTP/3, e soprattutto ci vorranno molto tempo e investimenti per fare in modo che si crei in circolo virtuoso nella sua implementazione. Ci vorranno anni prima che firewall, load balancer, proxie, sistemi SIEM, e via dicendo, supporteranno HTTP/3.
Nel frattempo, si ricorrerà, inevitabilmente, a magheggi per far convivere HTTP/2, se non HTTP/1.1 o addirittura HTTP/1.0, col nuovo arrivato. Di conseguenza, ci sarà un lungo periodo fatto di forward e downgrade delle connessioni su cui difficilmente si avrà visione e questo, come ben sappiamo, si tradurrà in possibili vulnerabilità.
Fermo restando che HTTP/3 è e rimane un protocollo ancora “sperimentale”: solo la prova del tempo sancirà con quali criticità avremo a che fare. Perché, lo sappiamo, nessuna tecnologia potrà mai dirsi sicura per sempre.
