Transport Layer Security: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
fix
 
(44 versioni intermedie di 27 utenti non mostrate)
Riga 1:
'''Transport Layer Security''' ('''TLS''') e il suo predecessore '''Secure Sockets Layer''' ('''SSL'''), le cui versioni SSL v2 e v3 sono considerate insicure, sono dei [[Protocollo di retecrittografico|protocolli crittografici]] a [[crittografia|crittograficilivello di presentazione]] (operando al di sopra del [[livello di presentazione|presentazionetrasporto]]) usati nel campo delle [[telecomunicazioni]] e dell'[[informatica]] che permettono una comunicazione [[sicurezza informatica|sicura]] dalla sorgente al destinatario (''end-to-end'') su reti [[TCP/IP]] (come ad esempio [[Internet]]) fornendo [[autenticazione]], [[integrità dei dati]] e [[cifratura]] operando al di sopra del [[livello di trasportoconfidenzialità]].
 
Diverse versioni del protocollo sono ampiamente utilizzate in applicazioni come i [[browser]], l'[[e-mail]], la [[messaggistica istantanea]] e il [[voice over IP]]. Un esempio di applicazione di SSL/TLS è nel protocollo [[HTTPS]].
 
{| class="wikitable sortable" style="float:right; text-align:center; margin-left:1em;"
|+Protocolli SSL e TLS
|-
!scope="col"| Protocollo
!scope="col"| Pubblicato
!scope="col"| Status
|-
!scope="row"| SSL 1.0
| {{n/a|Non pubblicato}}
| {{n/a|Non pubblicato}}
|-
!scope="row"| SSL 2.0
| 1995
|Deprecato nel 2011 (RFC 6176)
|-
!scope="row"| SSL 3.0
| 1996
|Deprecato nel 2015 (RFC 7568)
|-
!scope="row"| TLS 1.0
| 1999
|Deprecato nel 2021 (RFC 8996)
|-
!scope="row"| TLS 1.1
| 2006
|Deprecato nel 2021 (RFC 8996)
|-
!scope="row"| TLS 1.2
| 2008
|
|-
!scope="row"| TLS 1.3
| 2018
|Attuale ([https://datatracker.ietf.org/doc/html/rfc8446 RFC8446)]
|}
 
== Storia ==
Lo stack protocollare [[TCP/IP]] di [[Internet]], diversamente dal [[modello ISO/OSI]], non prevede di per sé funzionalità di sicurezza per motivi storici legati all'uso principale della rete ai suoi primordi (semplice scambio di dati tra ricercatori nella [[comunità scientifica]]), e solo successivamente con l'apertura della Rete a fini pubblici le problematiche di sicurezza sono diventate via via sempre più importanti da cui la necessità di inserire degli strati aggiuntivi che si occupino appunto di sicurezza<ref>[{{Cita web |url=http://www.isticom.it/documenti/news/pub_002_ita.pdf |titolo=Progetto1.qxd<!-- Titolo generato automaticamente -->] |accesso=28 marzo 2012 |dataarchivio=17 giugno 2012 |urlarchivio=https://web.archive.org/web/20120617101101/http://www.isticom.it/documenti/news/pub_002_ita.pdf |urlmorto=sì }}</ref>.
 
Le prime implementazioni di SSL erano limitate a [[Crittografia simmetrica|cifratura a chiave simmetrica]] di soli 40 bit a causa delle restrizioni imposte dal governo statunitense sull'esportazione di tecnologie crittografiche, per motivi di sicurezza nazionale. In altri termini, la limitazione della dimensione delle chiavi a 40 bit è stata esplicitamente imposta per rendere la cifratura abbastanza debole da potere essere forzata (tramite l'uso di tecniche di ricerca [[Metodo forza bruta|brutea forceforza bruta]]) dalle autorità giudiziarie che volessero decifrare il [[traffico (telecomunicazioni)|traffico]] cifrato, ma sufficientemente resistente agli attacchi da parte di entità con minori disponibilità di risorse tecnologico-finanziarie. Dopo diversi anni di controversie pubbliche, cause e l'ammissione da parte del governo statunitense di disponibilità sul mercato di prodotti per la cifratura 'migliori' (sia all'interno che al di fuori degli Stati Uniti), alcuni aspetti delle restrizioni sono stati modificati. Le implementazioni moderne utilizzano chiavi per la cifratura simmetrica a 128 (o più) bit.<ref>[{{Cita web |url=http://pralab.diee.unica.it/sites/default/files/Tesi_IginoCorona.pdf |titolo=HTTPGuard, un sistema per la rilevazione di attacchi contro Web server] |accesso=4 novembre 2013 |dataarchivio=13 aprile 2014 |urlarchivio=https://web.archive.org/web/20140413141026/http://pralab.diee.unica.it/sites/default/files/Tesi_IginoCorona.pdf |urlmorto=sì }}</ref><ref>[http://www.docstoc.com/docs/89330981/VPN VPN]</ref>
 
TLS è stato in seguito esteso da altri [[Request for Comments|RFC]], tra i quali:
 
* RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". Illustra come le cifrature a 40 bit siano ormai superate.
* RFC 2817: "Upgrading to TLS Within HTTP/1.1", Spiega come utilizzare il meccanismo di Upgrade in HTTP/1.1 per inizializzare il Transport Layer Security (TLS) su di una connessione TCP esistente. Questo permette di condividere la stessa ''well known port'' port tra traffico HTTP normale e sicuro.
* RFC 2818: "HTTP Over TLS". Differenziare il traffico sicuro da quello non sicuro tramite l'uso di una porta differente del server.
* RFC 3268: "AES Ciphersuites for TLS". Aggiunta di migliorie come l'[[Advanced Encryption Standard]] (AES), l'[[International Data Encryption Algorithm]] (IDEA), il [[Data Encryption Standard]] (DES) e il [[Triple DES]].
 
Attualmente le versioni SSL v2 e v3 sono considerate insicure. Di TLS vengono solitamente usate le versioni 1.2 e 1.3.<ref name=":2">{{Cita web|url=https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/|titolo=Apple, Google, Microsoft, and Mozilla come together to end TLS 1.0|cognome=Bright|nome=Peter|data=17 ottobre 2018|accesso=17 ottobre 2018}}</ref>
 
Anche se attualmente un numero sempre maggiore di prodotti client e server supportano TLS o SSL in modo nativo, esistono ancora molti prodotti che non supportano tali protocolli. In questi casi è possibile fare uso di prodotti che forniscono una cifratura SSL a sé stante.
 
== Descrizione ==
Il protocollo TLS consente alle applicazioni [[Sistema client/server|client/server]] di comunicare attraverso una rete in modo tale da prevenire il ''tampering'' (manomissione) dei dati, la falsificazione e l'intercettazione. È un protocollo [[standard (informatica)|standard]] [[Internet Engineering Task Force|IETF]] che, nella sua ultima versione, è definito nella RFC 5246, sviluppata sulla base del precedente protocollo SSL da [[Netscape Communications]].
 
Nell'utilizzo tipico di un browser da parte di utente finale, l'[[autenticazione]] TLS è ''unilaterale'': è il solo server ad autenticarsi presso il client (il client, cioè, conosce l'identità del server, ma non viceversa cioè il client rimane anonimo e non autenticato sul server). L'autenticazione del server è molto utile per il [[software]] di navigazione e per l'utente. Il browser valida il certificato del server controllando che la [[firma digitale]] dei certificati del server sia valida e riconosciuta da una [[certificate authority]] conosciuta utilizzando una cifratura a [[chiave pubblica]]. Dopo questa autenticazione il browser indica una connessione sicura mostrando solitamente l'icona di un lucchetto.
 
Questa autenticazione, però, non è sufficiente per garantire che il sito con cui ci si è collegati sia quello richiesto. Per esserne sicuri è necessario analizzare il contenuto del certificato rilasciato e controllarne la catena di certificazione. I siti che intendono ingannare l'utente non possono utilizzare un certificato del sito che vogliono impersonare perché non hanno la possibilità di cifrare in modo valido il certificato, che include l'indirizzo, in modo tale che risulti valido alla destinazione. Solo le [[Certificate authority|CA]] possono generare certificati validi con un'[[Uniform Resource Locator|URL]] incorporata in modo che il confronto fra l'URL apparente e quella contenuta nel certificato possa fornire un metodo certo per l'identificazione del sito. Molto spesso questo meccanismo non è noto agli utenti di internet ed è causa di varie frodi dovute ad un uso non corretto del browser, non ad una debolezza del protocollo TLS.
 
Il protocollo TLS permette anche un'autenticazione ''bilaterale'', tipicamente utilizzata in applicazioni aziendali, in cui entrambe le parti si autenticano in modo sicuro scambiandosi i relativi certificati. Questa autenticazione (definita [[Mutualmutua authenticationautenticazione]]) richiede che anche il client possieda un proprio [[certificato digitale]] cosa molto improbabile in un normale scenario.
 
In assenza di un'autenticazione bilaterale si possono utilizzare i protocolli [[TLS-PSK]] o [[Secure remote password]] (SRP) per garantire un'autenticazione sicura in assenza di un certificato.
 
Alcuni client, in fase di creazione del profilo di posta, hanno l'impostazione "TLS/SSL Accetta tutti i certificati" che equivale a “Ignora avvisi TLS/SSL”, avvisi cioè generati dal sistema operativo, in quanto se si utilizzano certificati attendibili, non occorre abilitare questa opzione al fine di consentire al client di creare il profilo dell’account. Questa istruzione è solitamente presente nella guida del provider di posta.
 
== Principi di funzionamento ==
=== Fasi ===
Il funzionamento del protocollo TLS può essere suddiviso in tre fasi principali:
 
* Negoziazione fra le parti dell'algoritmo da utilizzare
* [[Scambio delle [[Chiave crittografica|chiavi]] e [[autenticazione]]
* [[Crittografia simmetrica|Cifratura simmetrica]] e autenticazione dei messaggi
 
Nella prima fase, il client e il server negoziano il protocollo di cifratura che sarà utilizzato nella comunicazione sicura, il protocollo per lo scambio delle chiavi e l'algoritmo di autenticazione nonché il [[Message authentication code]] (MAC). L'algoritmo per lo scambio delle chiavi e quello per l'autenticazione normalmente sono algoritmi a [[chiave pubblica]] o, come nel caso di TLS-PSK, fanno uso di [[Pre-Shared Key|una chiave precondivisa]] ([[Pre-Shared Key]]). L'integrità dei messaggi è garantita da ununa [[Hash#Algoritmo di hash|algoritmofunzione di hash]] che usa un costrutto [[HMAC]] per il protocollo TLS o una funzione pseudorandom non standard per il protocollo SSL.
 
=== Protocolli impiegati ===
All'interno di una sessione tipicamente vengono utilizzati i seguenti protocolli:
* Per lo scambio di chiavi: [[RSA (crittografia)|RSA]], [[Diffie-Hellman]], [[Elliptic Curve Diffie-Hellman|ECDH]], [[Secure remote password|SRP]], [[Pre-Shared Key|PSK]]
 
* Per lo scambio di chiavil'autenticazione: [[RSA]], [[Diffie-Hellman(crittografia)|RSA]], [[EllipticDigital CurveSignature Diffie-HellmanAlgorithm|ECDHDSA]], [[SecureElliptic remoteCurve password|SRP]],Digital [[Pre-SharedSignature KeyAlgorithm|PSKECDSA]]
* Per l'autenticazione: [[RSA]], [[Digital Signature Algorithm|DSA]], [[Elliptic Curve Digital Signature Algorithm|ECDSA]]
* Cifratura simmetrica: [[RC4]], [[Data Encryption Standard|DES]], [[Triple DES]], [[Advanced Encryption Standard|AES]], [[International Data Encryption Algorithm|IDEA]] o [[Camellia (cifrario)|Camellia]]. Nelle vecchie versioni di SSL era anche utilizzato il protocollo [[RC2]].
* Per le funzioni crittografiche d'integrità si usano usualmente funzioni di [[hash]]: in TLS sono utilizzati [[HMAC|HMAC-MD5]] o [[HMAC|HMAC-SHA]], mentre in SSL [[MD5]] e [[Secure Hash Algorithm|SHA]]. Nelle versioni più vecchie di SSL erano anche utilizzati [[MD2]] e [[MD4]].
 
SSLv2 non utilizzava l'RSA. Esiste una vulnerabilità per cui un hacker può tentare ripetutamente di connettersi usando SSLv2, ottenendo ogni volta alcune informazioni sulla [[Chiave (crittografia)|chiave crittografica]]. Alcuni ''client'', oltre al supporto a TLS, negli anni hanno mantenuto il supporto al precedente SSLv2, senza disabilitarlo; IIS, il [[server web]] di Microsoft, a partire dalla versione 7.0, e [[OpenSSL]] a partire dalla versione 1.0.2g (Marzo 2016) disabilitano SSLv2 per impostazione predefinita.
 
== STARTTLS ==
'''STARTTLS''' è l'evoluzione del '''TLS''', si differenzia per il fatto che consente di cifrare la connessione anche sulle porte originali o standard, ossia 110, 143 e 25, in questo caso il client che sfrutta tale protocollo chiede in prima istanza al server l'instaurazione di una connessione cifrata, quindi la sessione inizia "in chiaro" per poi diventare cifrata prima che venga trasmessa qualunque informazione sensibile o potenzialmente tale.<ref>[https://www.ilsoftware.it/articoli.asp?tag=Email-SSL-TLS-e-STARTTLS-Differenze-e-perche-usarli_13031 Email: SSL, TLS e STARTTLS. Differenze e perché usarli]</ref>
 
== Note ==
<references />
 
== Bibliografia ==
* {{RivistaVG|mc|186|276-280|7/8|1998|titolo=Secure Sockets Layer}}
 
== Voci correlate ==
* [[Datagram Transport Layer Security]]
* [[Handshake]]
* [[OpenSSL]] - Implementazione ''[[open source]]''
Line 62 ⟶ 103:
 
== Altri progetti ==
{{interprogetto|commonspreposizione=Category:SSL and TLSsul}}
 
== Collegamenti esterni ==
* {{Collegamenti esterni}}
* {{FOLDOC|Transport Layer Security protocol}}
* {{cita web|https://letsencrypt.org/about/|Let's Encrypt.org}}
* RFC 2246: The TLS Protocol, Version 1.0
* RFC 4346: The TLS Protocol, Version 1.1
* [[rfc:5246|RFC 5246]]: The TLS Protocol, Version 1.2
* {{cita web |http 1 = https://www.openssl.org/ | 2 = OpenSSL.org - Risorsa gratuita | accesso = 5 maggio 2019 | urlarchivio = https://web.archive.org/web/20140414075014/https://www.openssl.org/ | dataarchivio = 14 aprile 2014 | urlmorto = sì }}
* {{cita web|http://www.compago.it/index.php/manuali/34-linux/166-connessioni-tunnel-con-ssh|Guida alle connessioni tunnel con SSH (forwarding)}}
 
{{IPstack}}
{{portale|crittografia|informatica|Sicurezza informatica|Telematica}}
 
[[Categoria:Protocolli livello applicazionepresentazione]]
[[Categoria:Protocolli crittografici]]
[[Categoria:Sicurezza indi rete]]