TLS o Transport Layer Security è il protocollo utilizzato unitamente ad HTTPS per garantire mediante cifratura la sicurezza ed integrità dei dati scambiati tra client e server.
L’IETF (Internet Engineering Task Force), dopo circa ventotto revisioni, è riuscito infine ad approvare all’unanimità la versione 1.3 di TLS. Tra i motivi alla base dei continui rinvii anche i cosiddetti middleboxes, dispositivi che si occupano di controllare e filtrare il traffico di rete (es: firewall, intrusion detection system etc).
Come spiegato da uno degli sviluppatori coinvolti nell’implementazione di TLS 1.3, ci sono ancora alcune criticità da risolvere in merito ad uno dei passaggi riguardanti il processo di comunicazione tra client e server, nello specifico il CLIENT HELLO.
Alcune applicazioni non funzionano con [TLS 1.3] perché… il CLIENT HELLO non è eseguito correttamente e ciò causa il fallimento dell’handshake
ha affermato Loganaden Velvindron interpellato dal portale The Register in occasione della convention IETF 101 (Londra, 17-23 marzo 2018).
Le specifiche approvate dall’IETF prevedono una sorta di modalità di compatibilità per i middleboxes ma servirà in ogni caso tempo affinché il sistema sia adottato su larga scala. Dall’esterno la connessione sembrerà utilizzare il “vecchio” TLS 1.2 ma si tratterà in realtà dell’1.3, ha aggiunto Velvindron.
Nel caso in cui l’implementazione di TLS 1.2 non sia ottimale, la connessione sarà interrotta e gli utenti riceveranno una notifica – la strumentazione necessiterà in seguito di un aggiornamento del firmware. Per raggiungere la soluzione appena descritta sono stati impiegati circa 4 anni, suggerisce l’editorialista.
Caratteristiche attuali e future
Le novità introdotte nel nuovo standard sono interessanti:
– la sicurezza è stata ulteriormente incrementata grazie all’impiego di nuovi algoritmi di cifratura ed hashing più avanzati come x25519 e Ed25519. Anche gli attacchi che mirano al downgrade del protocollo in uso sono stati resi più complicati da mettere a segno (ulteriori informazioni nell’immagine);
– il tempo impiegato per portare a termine la procedura di handshake è stato abbassato. Nel caso in cui il client si colleghi ad host già contattati in precedenza, funzionalità come TLS False Start ed RTT ridurranno ulteriormente la durata dell’handshake;
– DNS privacy. Tra i prossimi obiettivi rivelati da Velvindron la riduzione delle perdite di dati (leak) dei pacchetti. Grazie al DNS Padding (proposto nell’RFC 7830) questi ultimi assumeranno una dimensione standard rendendo vani i tentativi di eventuali malintenzionati che analizzano i pacchetti in transito – determinate dimensioni possono infatti suggerire il contenuto del pacchetto.
Da ricordare infatti in chiusura la dichiarazione di Velvindron circa le difficoltà riguardanti la gestione del DNS. Con circa 185 RFC (Request for Comments) in archivio ed un ridotto numero di membri in grado di conoscere, anche a grandi linee, tutti gli standard proposti e/o attivi, il DNS si sta rivelando difficile da supervisionare adeguatamente.
A complicare ulteriormente la situazione il fatto che le nuove funzionalità non siano testate sul campo per verificarne la compatibilità o meno con altre feature già presenti. Uno schema organizzativo sicuramente da rivedere, commenta Velvindron, il quale auspica un cambio di rotta e, come sottolineato dagli altri partecipanti all’IETF 101, il coinvolgimento diretto degli ISP – per velocizzare le implementazioni future e ridurre i potenziali imprevisti.
Per quanto riguarda l’adozione di TLS 1.3 le tempistiche sono abbastanza lunghe…