Passa al contenuto principale

Appendice E. Retrocompatibilità (Backward Compatibility)

Questa appendice discute i problemi di compatibilità tra TLS 1.2 e le versioni precedenti.

E.1. Compatibilità con TLS 1.0/1.1 e SSL 3.0 (Compatibility with TLS 1.0/1.1 and SSL 3.0)​

A causa di nuove funzionalità e alcuni cambiamenti strutturali, non esiste interoperabilità diretta tra TLS 1.2 e TLS 1.1, TLS 1.0 e SSL 3.0. Tuttavia, TLS 1.2 contiene un meccanismo mediante il quale un'implementazione TLS 1.2 può negoziare con versioni precedenti.

E.1.1. Negoziazione della versione​

TLS fornisce un meccanismo integrato per la negoziazione della versione come parte dell'handshake:

  1. Versione in ClientHello:

    • Il client indica la versione più alta che supporta nel ClientHello
    • Le implementazioni DOVREBBERO indicare TLS 1.2 (versione 3) nel ClientHello

  2. Versione in ServerHello:

    • Il server seleziona la versione più alta supportata sia da sé che dal client
    • Se il server non supporta la versione suggerita dal client, seleziona una versione inferiore

  3. Versione del livello di record:

    • La versione del record ClientHello DOVREBBE essere impostata su 1 (TLS 1.0) per la massima compatibilità
    • I record successivi utilizzano la versione negoziata

E.1.2. Estensioni​

TLS 1.2 introduce nuove estensioni e modifiche alle estensioni esistenti:

  • Estensione signature_algorithms: I client TLS 1.2 DEVONO includere questa estensione
  • I server di versioni precedenti ignoreranno le estensioni che non comprendono

E.1.3. Suite di cifratura​

Alcune suite di cifratura sono specifiche per TLS 1.2:

  • Suite di cifratura che utilizzano la PRF SHA-256
  • Nuove suite di cifratura AEAD

Quando si negozia con versioni precedenti, queste suite di cifratura NON DOVREBBERO essere offerte nel ClientHello.

E.1.4. Raccomandazioni per l'implementazione​

Le implementazioni client DOVREBBERO:

  • Supportare più versioni TLS
  • Annunciare la versione più alta supportata nel ClientHello
  • Essere pronte ad accettare una versione inferiore
  • Implementare la protezione contro il fallback di versione (SCSV)

Le implementazioni server DOVREBBERO:

  • Supportare più versioni TLS per un'ampia compatibilità
  • Preferire la versione di protocollo più alta
  • Gestire correttamente i ClientHello delle versioni precedenti

Esempio di flusso di negoziazione:

Client (supporta TLS 1.2, 1.1, 1.0)
  -> ClientHello (version=3.3)
     Versioni supportate: TLS 1.2, 1.1, 1.0

Server (supporta solo TLS 1.1, 1.0)
  <- ServerHello (version=3.2)
     Selezionato: TLS 1.1

La connessione continua utilizzando TLS 1.1

E.2. Compatibilità con SSL 2.0 (Compatibility with SSL 2.0)​

SSL 2.0 NON DOVREBBE essere utilizzato nelle nuove implementazioni. Tuttavia, per la compatibilità con i sistemi legacy, alcune implementazioni potrebbero dover comprendere i ClientHello in formato SSL 2.0.

E.2.1. ClientHello SSL 2.0​

Il ClientHello SSL 2.0 ha un formato diverso:

uint16 msg_length;          /* Il bit più alto DEVE essere 1 */
uint8 msg_type;             /* DEVE essere 1 */
Version version;            /* Versione desiderata dal client */
uint16 cipher_spec_length;  /* Non può essere 0 */
uint16 session_id_length;   /* DEVE essere 0 o 16 */
uint16 challenge_length;    /* Non può essere 0 */
CipherSpec cipher_specs[...];
SessionID session_id;
Challenge challenge;

E.2.2. Gestione del ClientHello SSL 2.0​

Un server TLS 1.2 PUÒ accettare un ClientHello incapsulato in formato SSL 2.0, ma DEVE:

  1. Controllare il bit più alto di msg_length
  2. Verificare la validità del formato
  3. Convertirlo in formato TLS per l'elaborazione
  4. Rispondere con un ServerHello in formato TLS

E.2.3. Considerazioni sulla sicurezza​

Importante: Il supporto dei ClientHello in formato SSL 2.0 non significa supportare il protocollo SSL 2.0 stesso. SSL 2.0 ha molte vulnerabilità di sicurezza note e NON DEVE essere negoziato per l'uso.

E.2.4. Raccomandazioni per l'implementazione​

  • I client TLS 1.2 NON DEVONO inviare ClientHello in formato SSL 2.0
  • Il supporto del server per i ClientHello in formato SSL 2.0 è ora PUÒ, piuttosto che DOVREBBE
  • L'invio di ClientHello in formato SSL 2.0 è NON DOVREBBE
  • Le future versioni TLS potrebbero cambiare questo in NON DOVREBBE supportare

E.3. Evitare il rollback della versione man-in-the-middle (Avoiding Man-in-the-Middle Version Rollback)​

Le versioni precedenti del protocollo erano vulnerabili agli attacchi di rollback della versione in cui un attaccante poteva forzare una connessione a utilizzare una versione di protocollo precedente (più debole).

E.3.1. Meccanismi di protezione​

TLS 1.2 utilizza più meccanismi per prevenire il rollback della versione:

  1. Verifica del messaggio Finished:

    • Il messaggio Finished contiene un hash di tutti i messaggi di handshake
    • Include i campi di versione da ClientHello e ServerHello
    • Qualsiasi modifica della versione causerà il fallimento della verifica di Finished

  2. TLS_FALLBACK_SCSV:

    • Valore di suite di cifratura di segnalazione definito in RFC 7507
    • I client includono questo valore quando ritentano una connessione con una versione inferiore
    • Il server rifiuta la connessione se supporta una versione superiore

E.3.2. Requisiti di implementazione​

I client DEVONO:

  • Registrare le versioni precedentemente tentate
  • Includere TLS_FALLBACK_SCSV quando si riprova con downgrade
  • Verificare il messaggio Finished

I server DEVONO:

  • Controllare la presenza di TLS_FALLBACK_SCSV
  • Inviare un avviso inappropriate_fallback se è supportata una versione superiore
  • Calcolare e verificare correttamente il messaggio Finished

E.3.3. Scenari di esempio​

Connessione normale:

Client -> ClientHello (TLS 1.2)
Server <- ServerHello (TLS 1.2)
... Handshake normale ...
Successo!

Downgrade legittimo:

Client -> ClientHello (TLS 1.2)
Server <- ServerHello (TLS 1.1)
... Handshake TLS 1.1 ...
Successo!

Attacco rilevato:

Client -> ClientHello (TLS 1.2)
L'attaccante modifica in (TLS 1.0)
Server <- ServerHello (TLS 1.0)
... L'handshake continua ...
Client -> Finished (verifica fallita!)
Connessione interrotta!

Nuovo tentativo con SCSV:

Client -> ClientHello (TLS 1.2) - Fallisce
Client -> ClientHello (TLS 1.1, TLS_FALLBACK_SCSV)
Il server rileva SCSV e supporta TLS 1.2
Server <- Alert: inappropriate_fallback
Connessione interrotta - Attacco di downgrade rilevato!

Nota: Per informazioni complete sulla compatibilità e spiegazioni dettagliate, si prega di fare riferimento al testo completo dell'appendice E della RFC 5246.

Ultimo aggiornamento il