Passa al contenuto principale

1. Introduction (Introduzione)

L'obiettivo principale del protocollo TLS è fornire privacy e integrità dei dati tra due applicazioni comunicanti. Il protocollo è composto da due livelli: il protocollo di record TLS (TLS Record Protocol) e il protocollo di handshake TLS (TLS Handshake Protocol). Al livello più basso, stratificato sopra un protocollo di trasporto affidabile (ad esempio, TCP [TCP]), si trova il protocollo di record TLS. Il protocollo di record TLS fornisce sicurezza della connessione che ha due proprietà fondamentali:

  • La connessione è privata. La crittografia simmetrica viene utilizzata per la cifratura dei dati (ad esempio, AES [AES], RC4 [SCH]). Le chiavi per questa cifratura simmetrica sono generate in modo univoco per ciascuna connessione e si basano su un segreto negoziato da un altro protocollo (come il protocollo di handshake TLS). Il protocollo di record può essere utilizzato anche senza cifratura.

  • La connessione è affidabile. Il trasporto dei messaggi include un controllo di integrità del messaggio utilizzando un MAC con chiave. Funzioni hash sicure (ad esempio, SHA-1, ecc.) vengono utilizzate per i calcoli MAC. Il protocollo di record può operare senza MAC, ma generalmente viene utilizzato in questa modalità solo quando un altro protocollo sta utilizzando il protocollo di record come trasporto per negoziare i parametri di sicurezza.

Il protocollo di record TLS viene utilizzato per incapsulare vari protocolli di livello superiore. Uno di questi protocolli incapsulati, il protocollo di handshake TLS, consente al server e al client di autenticarsi reciprocamente e di negoziare un algoritmo di cifratura e chiavi crittografiche prima che il protocollo applicativo trasmetta o riceva il suo primo byte di dati. Il protocollo di handshake TLS fornisce sicurezza della connessione che ha tre proprietà fondamentali:

  • L'identità del peer può essere autenticata utilizzando la crittografia asimmetrica o a chiave pubblica (ad esempio, RSA [RSA], DSA [DSS]). Questa autenticazione può essere resa opzionale, ma è generalmente richiesta per almeno uno dei peer.

  • La negoziazione di un segreto condiviso è sicura: il segreto negoziato non è disponibile per gli intercettatori e, per qualsiasi connessione autenticata, il segreto non può essere ottenuto, anche da un attaccante che può posizionarsi al centro della connessione.

  • La negoziazione è affidabile: nessun attaccante può modificare la comunicazione di negoziazione senza essere rilevato dalle parti della comunicazione.

Un vantaggio di TLS è che è indipendente dal protocollo applicativo. I protocolli di livello superiore possono stratificarsi trasparentemente sopra il protocollo TLS. Tuttavia, lo standard TLS non specifica come i protocolli aggiungono sicurezza con TLS; le decisioni su come avviare l'handshake TLS e su come interpretare i certificati di autenticazione scambiati sono lasciate al giudizio dei progettisti e degli implementatori dei protocolli che vengono eseguiti sopra TLS.

1.1. Requirements Terminology (Terminologia dei requisiti)​

Le parole chiave "MUST" (deve), "MUST NOT" (non deve), "REQUIRED" (richiesto), "SHALL" (deve), "SHALL NOT" (non deve), "SHOULD" (dovrebbe), "SHOULD NOT" (non dovrebbe), "RECOMMENDED" (raccomandato), "MAY" (può) e "OPTIONAL" (opzionale) in questo documento devono essere interpretate come descritto in RFC 2119 [REQ].

1.2. Major Differences from TLS 1.1 (Differenze principali da TLS 1.1)​

Questo documento è una revisione del protocollo TLS 1.1 [TLS1.1] che contiene una maggiore flessibilità, in particolare per la negoziazione degli algoritmi crittografici. Le principali modifiche sono:

  • La combinazione MD5/SHA-1 nella funzione pseudocasuale (PRF) è stata sostituita con PRF specificate dalla suite di cifratura. Tutte le suite di cifratura in questo documento utilizzano P_SHA256.

  • La combinazione MD5/SHA-1 nell'elemento firmato digitalmente è stata sostituita con un singolo hash. Gli elementi firmati ora includono un campo che specifica esplicitamente l'algoritmo hash utilizzato.

  • Pulizia sostanziale della capacità del client e del server di specificare quali algoritmi hash e di firma accetteranno. Si noti che questo rilassa anche alcuni dei vincoli sugli algoritmi di firma e hash delle versioni precedenti di TLS.

  • Aggiunta del supporto per modalità di cifratura autenticata con dati aggiuntivi (authenticated encryption with additional data modes).

  • Le definizioni delle estensioni TLS e le suite di cifratura AES sono state integrate da fonti esterne [TLSEXT] e [TLSAES].

  • Controllo più rigoroso dei numeri di versione EncryptedPreMasterSecret.

  • Inasprimento di una serie di requisiti.

  • La lunghezza di verify_data ora dipende dalla suite di cifratura (il valore predefinito è ancora 12).

  • Descrizione pulita delle difese contro gli attacchi Bleichenbacher/Klima.

  • Gli avvisi (Alerts) devono ora essere inviati in molti casi.

  • Dopo un certificate_request, se non sono disponibili certificati, i client devono ora inviare un elenco di certificati vuoto.

  • TLS_RSA_WITH_AES_128_CBC_SHA è ora la suite di cifratura obbligatoria da implementare.

  • Aggiunte suite di cifratura HMAC-SHA256.

  • Rimosse le suite di cifratura IDEA e DES. Sono ora deprecate e saranno documentate in un documento separato.

  • Il supporto per l'hello compatibile con SSLv2 è ora un MAY (può), non uno SHOULD (dovrebbe), e inviarlo è uno SHOULD NOT (non dovrebbe). Il supporto probabilmente diventerà uno SHOULD NOT (non dovrebbe) in futuro.

  • Aggiunta funzionalità "fall-through" limitata al linguaggio di presentazione per consentire a più rami case di avere la stessa codifica.

  • Aggiunta una sezione sui tranelli di implementazione (Implementation Pitfalls).

  • Le consuete chiarificazioni e lavoro editoriale.

Ultimo aggiornamento il