So che TLS è essenzialmente una versione più recente di SSL e che generalmente supporta la transizione di una connessione da non protetta a protetta (generalmente tramite un comando STARTTLS).
Quello che non capisco è il motivo per cui TLS è importante per un professionista IT e perché, data la scelta, sceglierei uno sopra l'altro. TLS è davvero solo una versione più recente e, in caso affermativo, è un protocollo compatibile?
Come professionista IT: quando utilizzo quale? Quando non uso quale?
Risposte:
Risposta breve:
SSL è il precursore di TLS. SSL era un protocollo proprietario sviluppato da Netscape Communications, successivamente standardizzato all'interno di IETF e ribattezzato TLS. In breve, le versioni vanno in questo ordine: SSLv2, SSLv3, TLSv1.0, TLSv1.1 e TLSv1.2.
Contrariamente a una credenza relativamente diffusa, non si tratta affatto di dover eseguire un servizio su una porta distinta con SSL e di poterlo utilizzare sulla stessa porta della variante in testo normale con TLS. Sia SSL che TLS possono essere utilizzati per i due approcci. Si tratta della differenza tra SSL / TLS al momento della connessione (a volte indicato come "SSL / TLS implicito") e SSL / TLS dopo che un comando è stato emesso a livello di protocollo, in genere STARTTLS(a volte indicato come "SSL / TLS esplicito") . La parola chiave in STARTTLSè "START", non TLS. È un messaggio, a livello di protocollo dell'applicazione, per indicare che è necessario passare a SSL / TLS, se non è stato avviato prima di uno scambio del protocollo dell'applicazione.
L'uso di entrambe le modalità dovrebbe essere equivalente, a condizione che il client sia configurato per aspettarsi SSL / TLS in un modo o nell'altro, in modo da non passare a una connessione in chiaro.
Risposta più lunga:
Per quanto ne so, SSLv1 non ha mai lasciato i laboratori. SSLv2 e SSLv3 erano protocolli sviluppati da Netscape. SSLv2 è stato considerato insicuro per un po ', poiché è soggetto a attacchi di downgrade. SSLv3 utilizza internamente (3,0)come numero di versione (all'interno del ClientHellomessaggio).
TLS è il risultato della standardizzazione come protocollo più aperto all'interno di IETF. (Penso di aver letto da qualche parte, forse nel libro di E. Rescorla, che il nome era stato scelto in modo tale che tutti i partecipanti ne fossero ugualmente insoddisfatti, in modo da non favorire una particolare azienda: questa è una pratica abbastanza comune negli standard corpo). Chi è interessato a come è stata effettuata la transizione può leggere le FAQ dell'elenco di conversazioni SSL ; ci sono più copie di questo documento in giro, ma la maggior parte dei collegamenti (a ) sono obsoleti.netscape.com
TLS utilizza messaggi molto simili (sufficientemente diversi da rendere incompatibili i protocolli, sebbene sia possibile negoziare una versione comune ). I TLS 1.0 , 1.1 e 1.2 ClientHello i messaggi utilizzano (3,1), (3,2), (3,3)per indicare il numero di versione, che mostra chiaramente la continuazione da SSL.
Ci sono maggiori dettagli sulle differenze di protocollo in questa risposta .
Quando uso quale? Quando non uso quale?
Usa la versione più alta che puoi, se possibile. In pratica, come fornitore di servizi, ciò richiederà ai tuoi utenti di avere client che supportano queste versioni. Come al solito, è sempre un esercizio di valutazione del rischio (preferibilmente supportato da un caso aziendale, se del caso). Detto questo, tagliare comunque SSLv2.
Inoltre, tieni presente che la sicurezza fornita da SSL / TLS non riguarda solo la versione che usi, ma anche la corretta configurazione: è sicuramente preferibile utilizzare SSLv3 con una suite di crittografia avanzata rispetto a TLSv1.0 con a con un debole (o suite di cifratura anonima / con crittografia nulla. Alcune suite di crittografia, considerate troppo deboli, sono state esplicitamente vietate dalle nuove versioni di TLS. Le tabelle nel provider SunJSSE Java 7 (e le loro note a piè di pagina) possono essere interessanti se si desidera ulteriori dettagli.
Sarebbe preferibile utilizzare TLS 1.1 almeno, ma purtroppo non tutti i client li supportano (ad es. Java 6). Quando si utilizza una versione precedente alla 1.1, vale sicuramente la pena cercare di mitigare la vulnerabilità BEAST .
In generale consiglierei il libro di Eric Rescorla - SSL e TLS: Progettazione e costruzione di sistemi sicuri, Addison-Wesley, 2001 ISBN 0-201-61598-3 a persone che vogliono davvero maggiori dettagli.
C'è un mito che dice che TLS ti consente di utilizzare la stessa porta mentre SSL non può. Questo non è vero (e lascerò fuori l' unificazione delle porte per questa discussione). Sfortunatamente, questo mito sembra essere stato propagato agli utenti dal fatto che alcune applicazioni come MS Outlook a volte offrono una scelta tra SSL e TLS nelle loro opzioni di configurazione quando in realtà significano una scelta tra SSL / TLS implicito ed esplicito. (Ci sono esperti SSL / TLS di Microsoft, ma sembra che non siano stati coinvolti nell'interfaccia utente di Outlook.)
Penso che il motivo per cui si verifica questa confusione sia dovuto alla STARTTLSmodalità. Alcune persone sembrano averlo capito come STARTTLS= TLS, ma non è così. La parola chiave in STARTTLSè "START", non TLS. Perché questo non è stato chiamato STARTSSLo STARTSSLORTLSè perché queste estensioni sono state specificate all'interno di IETF, che utilizzava solo i nomi utilizzati nelle sue specifiche (supponendo che il nome TLS sarebbe stato l'unico permanente, immagino).
Oggi la maggior parte dei server HTTPS è in grado di gestire TLS, ma alcuni anni fa la maggior parte delle persone utilizzava SSLv3 per HTTPS. HTTPS (a rigor di termini, standardizzato come HTTP su TLS ) stabilisce normalmente la connessione SSL / TLS su connessione TCP, quindi scambia i messaggi HTTP sul livello SSL / TLS. C'è un'eccezione a questo quando si utilizza un proxy HTTP in mezzo. In questo caso, il client si connette al proxy HTTP in chiaro (in genere sulla porta 3128), quindi emette il CONNECTcomando HTTP e, a condizione che la risposta abbia avuto esito positivo, avvia l'handshake SSL / TLS inviando unClientHelloMessaggio. Tutto ciò accade sulla stessa porta per quanto riguarda la connessione tra browser e proxy (ovviamente non tra proxy e server di destinazione: non è nemmeno la stessa macchina). Funziona perfettamente con SSLv3. Molti di noi in situazioni dietro un proxy lo avranno utilizzato su server che non supportano almeno TLS 1.0.
Questo è chiaramente fuori specifica, ma in pratica spesso funziona. A rigor di termini le specifiche parlano del passaggio a TLS (non SSL) dopo aver utilizzato il comando STARTTLS. In pratica, spesso funziona anche SSL (proprio come le specifiche "HTTP over TLS" comprende anche l'utilizzo di SSL anziché TLS). Puoi provarlo da solo. Supponendo che tu abbia un server SMTP o IMAP che supporti STARTTLS, usi Thunderbird, vai nelle preferenze, nelle opzioni avanzate, nell'editor di configurazione e spegni security.enable_tls. Molti server accetteranno comunque la connessione, semplicemente perché le loro implementazioni delegano il livello SSL / TLS a una libreria SSL / TLS che sarà generalmente in grado di gestire SSL e TLS allo stesso modo, a meno che non sia configurato per non farlo. Come afferma la FAQ di OpenLDAP "Mentre il meccanismo è progettato per l'uso con TLSv1, la maggior parte delle implementazioni tornerà a SSLv3 (e SSLv2) se necessario. ". Se non sei sicuro, controlla con uno strumento come Wireshark.
Molti client possono utilizzare TLS 1.0 (almeno) per i protocolli in cui la variante protetta si trova su una porta diversa. Ovviamente, esistono numerosi browser e server Web che supportano TLS 1.0 (o versioni successive) per HTTPS. Allo stesso modo, anche SMTPS, IMAPS, POPS e LDAPS possono utilizzare TLS. Non si limitano a SSL.
Quando uso quale? Quando non uso quale?
Tra SSL / TLS esplicito e implicito, non importa. Ciò che conta è che il tuo cliente sappia cosa aspettarsi ed è configurato in modo appropriato per farlo. Ancora più importante, dovrebbe essere configurato per rifiutare le connessioni di testo normale quando si prevede una connessione SSL / TLS, sia implicita che esplicita .
La principale differenza tra SSL / TLS esplicito e implicito sarà nella chiarezza delle impostazioni di configurazione.
Ad esempio, per LDAP, se il client è un server Apache Httpd ( mod_ldap- la sua documentazione riporta anche l'etichetta erroneamente la differenza tra SSL e TLS), è possibile utilizzare SSL / TLS implicito utilizzando un ldaps://URL (ad esempio AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) o utilizzare SSL esplicito / TLS utilizzando un parametro aggiuntivo (ad es AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS.).
C'è forse in generale un rischio leggermente inferiore quando si specifica il protocollo di sicurezza nello schema URL ( https, ldaps, ...) rispetto a quando in attesa del client per configurare un'impostazione aggiuntiva per abilitare SSL / TLS, perché possono dimenticare. Questo è discutibile. Potrebbero esserci anche problemi nella correttezza dell'implementazione dell'uno rispetto all'altro (ad esempio, penso che il client LDAP Java non supporti la verifica del nome host quando lo utilizza ldaps://, quando dovrebbe, mentre è supportato con ldap://+ StartTLS).
Nel dubbio, e per essere compatibile con più client, se possibile, non sembra arrecare alcun danno offrire entrambi i servizi quando il server lo supporta (il tuo server ascolterà due porte contemporaneamente). Molte implementazioni di server per protocolli che possono essere utilizzate con entrambe le modalità supporteranno entrambe.
È responsabilità del cliente non lasciarsi passare a una connessione in chiaro. Come amministratore del server, non c'è nulla che tu possa tecnicamente fare dalla tua parte per prevenire attacchi di downgrade (a parte forse richiedere un certificato client). Il client deve verificare che SSL / TLS sia abilitato, indipendentemente dalla connessione o dopo un STARTTLScomando simile. Allo stesso modo in cui un browser non dovrebbe lasciarsi reindirizzare da https://a http://, un client per un protocollo che supporta STARTTLS
dovrebbe assicurarsi che la risposta fosse positiva e che la connessione SSL / TLS fosse abilitata prima di procedere ulteriormente. Un utente malintenzionato MITM attivo potrebbe altrimenti effettuare il downgrade di entrambe le connessioni.
Ad esempio, le versioni precedenti di Thunderbird avevano una cattiva opzione per questo chiamata "Usa TLS, se disponibile" , il che implicava essenzialmente che se un attaccante MITM era in grado di modificare i messaggi del server in modo da non pubblicizzare il supporto per STARTTLS, il client si lasciava silenziosamente passare a una connessione in chiaro. (Questa opzione non sicura non è più disponibile in Thunderbird.)
TLS è un protocollo più recente di SSL (ma AFAIK, è compatibile con SSL v3). Di solito, c'è solo una differenza di cui devi preoccuparti:
Un protocollo SSL ha in genere una porta separata, ad esempio 80 per HTTP e 443 per HTTPS (HTTP / SSL). Quando ti connetti alla porta SSL, l'intera sessione viene crittografata.
TLS è più recente di SSL e non richiede una porta separata, ma deve essere negoziata dal client. Ad esempio, è possibile eseguire IMAP sulla porta 143 e se sia il server di posta che il client supportano TLS, il client invierà un STARTTLScomando e solo successivamente abiliterà la crittografia. In questo modo non è necessaria una porta solo SSL separata, pur rimanendo compatibile con le applicazioni senza SSL.
Riepilogo:
SSL : leggermente più vecchio. Porte separate per connessioni semplici e crittografate. Tutto il traffico sulla porta SSL è sempre crittografato.
TLS : porta singola per connessioni semplici e crittografate. La crittografia è abilitata solo dopo che il client ha inviato un STARTTLScomando.
STARTTLSdi alcuni protocolli consenta di passare a TLS sulla stessa connessione non fa differenza tra SSL e TLS. Tecnicamente potresti passare a SSLv3 allo stesso modo.
Da questo articolo della Knowledge Base dell'Università dell'Indiana :
SSL è l'acronimo di Secure Sockets Layer. Originariamente Netscape ha sviluppato questo protocollo per trasmettere informazioni in privato, garantire l'integrità dei messaggi e garantire l'identità del server. SSL funziona principalmente attraverso l'utilizzo della crittografia a chiave pubblica / privata sui dati. Viene comunemente utilizzato sui browser Web, ma SSL può essere utilizzato anche con server di posta elettronica o qualsiasi tipo di transazione client-server. Ad esempio, alcuni server di messaggistica istantanea utilizzano SSL per proteggere le conversazioni.
TLS è l'acronimo di Transport Layer Security. L'Internet Engineering Task Force (IETF) ha creato TLS come successore di SSL. Viene spesso utilizzato come impostazione nei programmi di posta elettronica, ma, come SSL, TLS può avere un ruolo in qualsiasi transazione client-server.
Le differenze tra i due protocolli sono molto minori e molto tecniche, ma sono standard diversi. TLS utilizza algoritmi di crittografia più potenti e ha la capacità di lavorare su porte diverse. Inoltre, TLS versione 1.0 non interagisce con SSL versione 3.0.
TLS è la versione più recente di SSL. Sebbene in alcuni punti queste parole possano significare qualcosa di diverso dai semplici protocolli, quindi chiarisci la tua domanda.