Non esiste un problema di sicurezza "reale" in TLS 1.1 che TLS 1.2 . Tuttavia, ci sono cambiamenti e miglioramenti, che possono essere discussi per qualificarsi come "fixing". Principalmente:
-
Il PRF in TLS 1.1 si basa su una combinazione di MD5 e SHA-1. Sia MD5 che SHA-1 sono, come funzioni hash crittografiche, interrotte. Tuttavia, il modo in cui sono interrotti non infrange il PRF di TLS 1.1. Non vi è alcuna debolezza nota nel PRF di TLS 1.1 (né, peraltro, nel PRF di SSL 3.0 e TLS 1.0). Tuttavia, MD5 e SHA-1 sono "cattiva stampa". TLS 1.2 sostituisce entrambi con SHA-256 (beh, in realtà potrebbe essere qualsiasi altra funzione di hash, ma in pratica è SHA-256).
-
TLS 1.2 consente l'uso delle modalità di crittografia autenticate come GCM. Questo può sostituire la modalità di crittografia CBC più tradizionale, che storicamente è stata fonte di molti difetti. La crittografia CBC correttamente implementata è ancora valida; tuttavia, sembra che implementando correttamente la crittografia CBC sia più facile a dirsi che a farsi. Ottenere il giusto GCM sembra un obiettivo più facilmente raggiungibile.
-
TLS 1.2 richiede il supporto per TLS_RSA_WITH_AES_128_CBC_SHA
mentre TLS 1.1 richiede solo TLS_RSA_WITH_3DES_EDE_CBC_SHA
. Pertanto, se utilizzi TLS 1.2, hai una "garanzia" che la crittografia AES sarà disponibile. (Questo in realtà non è completamente vero: la garanzia vale solo fino a quando non è richiesto un "profilo specifico dell'applicazione". Inoltre, si otterrà AES solo se sia il client che il server lo supportano, e se entrambi lo supportano, allora è disponibile, indipendentemente dal fatto che sia utilizzato TLS 1.1 o 1.2).
Per riepilogare , non è una cattiva idea correggere i tuoi server per supportare TLS 1.2 e configurarli per preferirlo su TLS 1.1, ma non c'è alcun vero difetto in TLS 1.1 che necessitava di correzione e rendere obbligatorio o addirittura raccomandato il passaggio a TLS 1.2. L'unità principale per l'adozione di TLS 1.2 è il solito desiderio pavloviano di qualcosa di nuovo e brillante.