Passa al contenuto principale

1. Introduzione

Il protocollo Transport Layer Security (TLS) versione 1.2 è specificato in [RFC5246]. Tale specifica include il framework per le estensioni di TLS, considerazioni nella progettazione di tali estensioni (vedere sezione 7.4.1.4 di [RFC5246]) e considerazioni IANA per l'allocazione di nuovi code point di estensione; tuttavia, non specifica alcuna estensione particolare diversa dagli algoritmi di firma (vedere sezione 7.4.1.4.1 di [RFC5246]).

Questo documento fornisce le specifiche per le estensioni TLS esistenti. Si tratta, per la maggior parte, dell'adattamento e modifica del materiale dall'RFC 4366, che copriva le estensioni TLS per TLS 1.0 (RFC 2246) e TLS 1.1 (RFC 4346).

1.1. Estensioni specifiche trattate​

Le estensioni qui descritte si concentrano sull'estensione delle funzionalità fornite dai formati dei messaggi del protocollo TLS. Altre questioni, come l'aggiunta di nuove suite di cifratura, sono rinviate.

I tipi di estensione definiti in questo documento sono:

enum {
    server_name(0), max_fragment_length(1),
    client_certificate_url(2), trusted_ca_keys(3),
    truncated_hmac(4), status_request(5), (65535)
} ExtensionType;

In particolare, le estensioni descritte in questo documento:

  • Consentono ai client TLS di fornire al server TLS il nome del server che stanno contattando. Questa funzionalità è desiderabile per facilitare connessioni sicure a server che ospitano più server 'virtuali' presso un singolo indirizzo di rete sottostante.

  • Consentono ai client e ai server TLS di negoziare la lunghezza massima del frammento da inviare. Questa funzionalità è desiderabile a causa di vincoli di memoria tra alcuni client e vincoli di larghezza di banda tra alcune reti di accesso.

  • Consentono ai client e ai server TLS di negoziare l'uso di URL dei certificati client. Questa funzionalità è desiderabile per conservare la memoria sui client vincolati.

  • Consentono ai client TLS di indicare ai server TLS quali chiavi radice dell'autorità di certificazione (CA) possiedono. Questa funzionalità è desiderabile per prevenire più fallimenti dell'handshake che coinvolgono client TLS che sono in grado di memorizzare solo un piccolo numero di chiavi radice CA a causa di limitazioni di memoria.

  • Consentono ai client e ai server TLS di negoziare l'uso di codici di autenticazione dei messaggi (MAC) troncati. Questa funzionalità è desiderabile per conservare la larghezza di banda nelle reti di accesso vincolate.

  • Consentono ai client e ai server TLS di negoziare che il server invii al client informazioni sullo stato del certificato (ad esempio, una risposta del protocollo OCSP (Online Certificate Status Protocol) [RFC2560]) durante un handshake TLS. Questa funzionalità è desiderabile per evitare l'invio di un elenco di revoca dei certificati (CRL) su una rete di accesso vincolata e quindi risparmiare larghezza di banda.

I client e i server TLS possono utilizzare le estensioni descritte in questo documento. Le estensioni sono progettate per essere retrocompatibili, il che significa che i client TLS che supportano le estensioni possono comunicare con server TLS che non le supportano, e viceversa.

Si noti che tutti i messaggi associati a queste estensioni che vengono inviati durante l'handshake TLS DEVONO essere inclusi nei calcoli hash coinvolti nei messaggi "Finished".

Si noti inoltre che tutte le estensioni definite in questo documento sono rilevanti solo quando viene avviata una sessione. Un client che richiede la ripresa della sessione generalmente non sa se il server accetterà questa richiesta e pertanto DOVREBBE inviare le stesse estensioni che invierebbe se non stesse tentando la ripresa. Quando un client include uno o più dei tipi di estensione definiti in un client hello esteso mentre richiede la ripresa della sessione:

  • L'estensione di indicazione del nome del server PUÒ essere utilizzata dal server nel decidere se riprendere o meno una sessione come descritto nella sezione 3.

  • Se la richiesta di ripresa viene negata, l'uso delle estensioni viene negoziato normalmente.

  • Se, d'altra parte, la sessione precedente viene ripresa, il server DEVE ignorare le estensioni e inviare un server hello che non contiene nessuno dei tipi di estensione. In questo caso, la funzionalità di queste estensioni negoziata durante l'avvio della sessione originale viene applicata alla sessione ripresa.

1.2. Convenzioni utilizzate in questo documento​

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC2119].

Ultimo aggiornamento il