Il mondo si sta muovendo verso TLS 1.3, che è un'ottima cosa! Questo articolo offre una panoramica di alto livello di TLS 1.3 e una discussione sull'efficacia delle sue nuove funzionalità.
Transport Layer Security
Transport Layer Security, o TLS, è un protocollo crittografico che protegge i dati scambiati su una rete di computer. TLS è diventato famoso come S in HTTPS. Più specificamente, TLS viene utilizzato per proteggere i dati degli utenti Web dagli attacchi di rete.
TLS è stato progettato come un'alternativa più sicura al suo predecessore Secure Sockets Layer (SSL). Nel corso degli anni, i ricercatori sulla sicurezza hanno scoperto un mucchio di vulnerabilità che interessano SSL, che hanno motivato IETF a progettare TLS nel tentativo di mitigarli.
Ironia della sorte, versioni precedenti di TLS sono stati anche colpiti da pericolose vulnerabilità, che alla fine hanno portato a TLS 1.2 (ovvero la versione predefinita consigliata dai professionisti del settore).
La maggior parte delle vulnerabilità note del protocollo sono state mitigate TLS 1.2, ma questo livello di sicurezza era ancora il risultato di una serie di patch su un design imperfetto.
Come risposta TLS 1.3 è stato redatto da zero nel tentativo di progettare in modo pulito un ambiente moderno e sicuro TLS protocollo. Cinque anni di test in seguito, è stato finalmente approvato ed è ora vicino allo standard di sicurezza Internet predefinito.
TLS le versioni e i rispettivi documenti RFC sono disponibili nell'elenco seguente:
- TLS 1.0 è stato pubblicato come RFC 2246 in 1996
- TLS 1.1 è stato pubblicato come RFC 4346 in 2006
- TLS 1.2 è stato pubblicato come RFC 5246 in 2008
- TLS 1.3 è stato pubblicato come standard proposto in RFC 8446 in 2018.
Come invecchiare TLS le versioni funzionano?
Discutere efficacemente i benefici di TLS 1.3, dobbiamo prima parlare di quanti anni ha TLS le versioni funzionano (e come non lo fanno).
TLS è un ibrido cryptosystem, nel senso che utilizza entrambi asimmetrico (chiave pubblica) e simmetrico crittografia (basata su password / frase). Questo è dovuto a crittografia asimmetrica essendo ordini di grandezza più lenti dei suoi equivalenti simmetrici.
Di conseguenza, TLS utilizza solo chiavi pubbliche in modo che client e server possano scambiare in modo sicuro una chiave simmetrica. Questa chiave può quindi essere utilizzata per crittografare tutte le comunicazioni successive, evitando l'overhead delle prestazioni imposto dalla crittografia asimmetrica.
TLS 1.2 supporta più algoritmi di scambio di chiavi (ad es. RSA, DH, ecc.), Insieme a diversi algoritmi (noto anche come cifrari) utilizzato per crittografare e decrittografare i messaggi. Questa grande quantità di opzioni alternative richiede a client e server di negoziare, in modo che tutte le parti utilizzino lo stesso TLS parametri.
Questa negoziazione è standardizzata in un protocollo chiamato stretta di mano. Se non lo si conosce, fare riferimento a Questo articolo per maggiori informazioni.
Quindi cosa c'è che non va TLS 1.2?
Sebbene il TLS 1.2 ha dimostrato di funzionare bene nella maggior parte dei casi, ci sono preoccupazioni per il livello generale di sicurezza e privacy che fornisce dopo anni di patch e revisioni.
A parte le considerazioni sulla sicurezza, però, TLS 1.2 impone inoltre prestazioni non necessarie e sovraccarico della rete.
TLS 1.2 problemi di sicurezza
Nel corso degli anni, i ricercatori (e gli aggressori) hanno scoperto una serie di vulnerabilità in molti TLS 1.2 componenti, tra cui algoritmi di scambio di chiavi, cifre e firme digitali. Alcuni di questi erano bug di implementazione di cui potresti aver sentito parlare, come ad esempio heartbleed or frenetico. Tuttavia, alcune erano vulnerabilità del protocollo, ovvero sfruttano decisioni di progettazione sbagliate in precedenza TLS versioni (cioè prima TLS 1.2).
Sebbene la maggior parte dell'implementazione e altri bug siano stati corretti TLS 1.2, purtroppo le vulnerabilità nella progettazione del protocollo non possono essere risolte utilizzando solo una patch software. A quanto pare, IETF ha dovuto riprogettare completamente il protocollo di handshake TLS 1.3
Ci sono state molte preoccupazioni in merito TLS sicurezza, ma una delle più importanti è stata la consapevolezza TLS 1.2 (e tutte le versioni precedenti, incluso SSL) è vulnerabile agli attacchi di downgrade a causa di un difetto nella progettazione del protocollo di handshake. Più specificamente, TLS 1.2 non utilizza le firme digitali per proteggere l'integrità della stretta di mano. Le firme proteggono parte dell'handshake, solo dopo la negoziazione della suite di crittografia.
Di conseguenza, gli aggressori possono manipolare qualsiasi negoziazione di suite di crittografia di terze parti che si verifica nella stessa rete di computer (ad esempio il wifi dell'aeroporto) e forzare l'uso di una cifra non sicura. Possono quindi rompere quella cifra vulnerabile e ottenere un accesso ingiustificato all'intera conversazione.
TLS 1.2 problemi di prestazioni
Oltre a queste considerazioni sulla sicurezza, TLS 1.2 necessità di negoziare numerosi TLS i parametri possono imporre un sovraccarico di prestazioni su HTTPS (o altro) TLS comunicazioni protette).
TLS L'handshake in 1.2 fasi di 4 richiede due scambi di andata e ritorno, prima per selezionare la suite di cifratura e poi per scambiare i certificati e le chiavi simmetriche (o condivisioni di chiavi).
Questo significa che per tutti TLS collegamento da stabilire, due transazioni aggiuntive con il server sono richiesti. Di conseguenza, TLS le connessioni richiedono più larghezza di banda e potenza rispetto all'HTTP (non crittografato), che può essere particolarmente costoso per le applicazioni Internet-of-Things (IoT), dove il basso consumo di energia e la larghezza di banda sono vincoli difficili.
TLS 1.2 problemi di privacy
Infine, TLS 1.2 è stato criticato per compromettere la privacy degli utenti web.
Più specificamente, TLS offre un'estensione nota come Indicazione nome server o SNI. SNI consente di includere il nome host di un server nell'handshake SSL iniziale. Questa estensione viene utilizzata per l'hosting virtuale, in cui i server possono servire più domini sullo stesso indirizzo IP e porta, presentando un certificato diverso per ogni dominio.
In TLS 1.2, SNI vengono inviati in chiaro, quindi nonostante l'uso di HTTPS, un utente malintenzionato della rete può perdere queste informazioni e tracciare le pagine Web visitate dall'utente.
Che aspetto ha e come funziona il TLS 1.3 risolvere tutto ciò?
TLS 1.2 (e versioni precedenti) erano focalizzati sul mantenimento della compatibilità con le versioni precedenti. Ogni versione costruita su quelle precedenti con revisioni minori che tentano di eliminare le vulnerabilità pubblicate tra TLS versioni.
Purtroppo, ciò significava anche che le cattive decisioni di progettazione del protocollo (ad esempio la stretta di mano non protetta) venivano ereditate anche nelle versioni più recenti.
TLS 1.3 abbandona la retrocompatibilità a favore di un adeguato progetto di sicurezza. È stato progettato da zero per fornire funzionalità simili (ma non compatibili) a TLS 1.2, ma con prestazioni, privacy e sicurezza notevolmente migliorate.
TLS Sicurezza 1.3
Un principio fondamentale di TLS 1.3 è semplicità. Nella nuova versione, tutti gli algoritmi di scambio delle chiavi, ad eccezione di Diffie-Hellman (DH) lo scambio di chiavi, sono stati rimossi. TLS 1.3 ha anche definito una serie di parametri DH collaudati, eliminando la necessità di negoziare i parametri con il server.
Cosa c'è di più, TLS 1.3 non supporta più cifre non necessarie o vulnerabili, come la modalità CBC e la cifra RC4. Questi numeri sono noti per essere sensibili agli attacchi, ma erano ancora supportati nella maggior parte TLS implementazioni per la compatibilità legacy. Fortunatamente, la recente corsa agli attacchi di downgrade ha interessato presto TLS le versioni hanno motivato IETF a rimuovere completamente tali cifre da TLS 1.3
Inoltre, TLS 1.3 richiede ai server di firmare crittograficamente l'intera stretta di mano, inclusa la negoziazione di cifratura, che impedisce agli aggressori di modificare i parametri della stretta di mano. Ciò significa che TLS 1.3 è architettonicamente impermeabile agli attacchi di downgrade che hanno interessato in precedenza TLS versioni.
Infine, anche le firme stesse sono state migliorate implementando un nuovo standard, chiamato RSA-PSS. Le firme RSA-PSS sono immuni agli attacchi crittografici che colpiscono gli schemi di firma utilizzati in precedenza TLS versioni.
TLS Nessuna prestazione
Oltre a una maggiore sicurezza, l'insieme ridotto di parametri e la stretta di mano semplificata TLS 1.3 contribuisce anche a migliorare le prestazioni complessive. Poiché esiste un solo algoritmo di scambio di chiavi (con parametri integrati) e solo una manciata di cifre supportate, la larghezza di banda assoluta richiesta per impostare un TLS Il canale 1.3 è notevolmente inferiore rispetto alle versioni precedenti.
Per di più, TLS 1.3 ora supporta un nuovo protocollo di handshake, chiamato Modalità 1-RTT. In 1-RTT, il client può inviare condivisioni chiave DH nel primo messaggio di handshake, poiché può essere abbastanza certo dei parametri che il server utilizzerà. Nel raro caso in cui il server non li supporti, può generare un errore in modo che il client invii una configurazione diversa.
Invece di negoziare prima i parametri e quindi scambiare chiavi o condivisioni di chiavi, TLS 1.3 consente a un client di configurare a TLS canale con una sola transazione di andata e ritorno (anziché due, come precedentemente fatto). Ciò può avere un grande effetto cumulativo nelle risorse di elaborazione, alimentazione e rete necessarie per consentire a un client di comunicare con un server tramite TLS 1.3
Le ottimizzazioni delle prestazioni non si fermano qui, però, con un altro TLS 1.3, chiamato il 0-RTT Modalità di ripresa. Quando un browser visita un server per la prima volta e completa correttamente a TLS stretta di mano, sia il client che il server possono archiviare localmente una chiave di crittografia precondivisa.
Se il browser visita nuovamente il server, può utilizzare questa chiave di ripristino per inviare al server i dati dell'applicazione crittografati nel suo primo messaggio. Ciò ha la stessa latenza dell'HTTP non crittografato, poiché non sono richiesti gli handshake iniziali.
Va notato che c'è stata una certa sicurezza preoccupazioni circa la modalità 0-RTT in passato.
TLS Riservatezza 1.3
Imparare dagli errori del passato, TLS 1.3 ora offre un estensione che crittografa le informazioni SNI. Se utilizzata correttamente, questa estensione impedisce agli aggressori di perdere il nome di dominio del server remoto, quindi non hanno alcun metodo per tenere traccia della cronologia utente HTTPS. Questa funzione fornisce una maggiore privacy agli utenti Internet rispetto alle versioni precedenti di TLS.
Conclusione
Mentre TLS 1.2 ha servito onorevolmente tutti questi anni, TLS 1.3 è decisamente più sicuro ed efficiente. TLS 1.3 è stato ampiamente testato nelle implementazioni sperimentali del browser ed è ora pronto per essere sostituito TLS 1.2 come protocollo di sicurezza di rete preferito. editoriale TLS 1.3 è un grande passo avanti verso un Internet più veloce e sicuro per tutti.
Grazie per aver scelto SSL.com, dove crediamo a più sicuro Internet è un better Internet.
