9. HTTP/2 Connections (Connessioni HTTP/2)
Le connessioni HTTP/2 sono protocolli a livello applicativo che operano su un trasporto affidabile [TCP] che utilizza Transport Layer Security (TLS) [TLS13] per proteggere i dati scambiati sulla rete.
HTTP/2 utilizza gli stessi schemi URI "http" e "https" di HTTP/1.1. HTTP/2 condivide gli stessi numeri di porta predefiniti: porta 80 per gli URI "http" e porta 443 per gli URI "https". Di conseguenza, le implementazioni devono gestire le richieste agli URI di risorse target come http://example.org/foo o https://example.com/bar scoprendo prima se il server upstream (il peer immediato al quale il client desidera stabilire una connessione) supporta HTTP/2.
9.1. Connection Management (Gestione delle Connessioni)
Le connessioni HTTP/2 sono persistenti. Per ottenere le migliori prestazioni, ci si aspetta che i client non chiudano le connessioni finché non si determina che non è necessaria ulteriore comunicazione con un server (ad esempio, quando un utente si allontana da una particolare pagina web) o finché il server non chiude la connessione.
I client NON DOVREBBERO aprire più di una connessione HTTP/2 a una data coppia host e porta, dove l'host è derivato da un URI, un servizio alternativo selezionato [ALT-SVC] o un proxy configurato.
Un client può creare connessioni aggiuntive come sostituzioni, sia per sostituire connessioni che stanno per esaurire lo spazio identificatore di stream disponibile (Sezione 5.1.1), per aggiornare il materiale di chiave per una connessione TLS, o per sostituire connessioni che hanno riscontrato errori (Sezione 5.4.1).
Un client PUÒ aprire più connessioni allo stesso target allo scopo di: creare nuove connessioni per tentare richieste atomiche (vedere Sezione 9.1.2), o sostituire qualsiasi identificatore di stream maggiore di 0 che è stato ricevuto in un frame GOAWAY e che è nello stato "attivo" o "inattivo" (vedere Sezione 6.8).
I server sono incoraggiati a mantenere aperte le connessioni il più a lungo possibile, ma sono autorizzati a terminare le connessioni inattive se necessario. Quando uno dei due endpoint sceglie di chiudere la connessione TCP a livello di trasporto, l'endpoint che termina DOVREBBE prima inviare un frame GOAWAY (Sezione 6.8) in modo che entrambi gli endpoint possano determinare in modo affidabile se i frame precedentemente inviati sono stati elaborati e completare o terminare con grazia tutte le attività rimanenti necessarie.
9.1.1. Connection Reuse (Riutilizzo delle Connessioni)
Le connessioni stabilite a un server di origine, sia direttamente sia attraverso un tunnel creato utilizzando il metodo CONNECT (Sezione 8.5), POSSONO essere riutilizzate per richieste con più componenti di autorità URI diversi. Una connessione può essere riutilizzata finché il server di origine è autorevole (Sezione 10.1). Per le connessioni TCP senza TLS, questo dipende dal fatto che l'host sia stato risolto allo stesso indirizzo IP.
Per le risorse "https", il riutilizzo delle connessioni dipende anche dal possedere un certificato valido per l'host nell'URI. Il certificato presentato dal server DEVE soddisfare tutti i controlli che il client effettuerebbe quando forma una nuova connessione TLS per l'origine.
Un server di origine può offrire un certificato con più origini, ciascuna delle quali è autorevole per l'uso della connessione. Ad esempio, un certificato può includere più nomi host nel campo subjectAltName. In alternativa, un nome host contenente un carattere jolly può essere applicabile anche ad altre origini.
In alcuni casi, l'autorità URI può differire dall'insieme di origini identificate nel certificato (ad esempio, alcune distribuzioni utilizzano URI per trasportare asserzioni di identità stabilite altrove), e altri attributi dell'autorità non corrispondono. Un client PUÒ tentare di utilizzare una connessione esistente ma DEVE inviare la richiesta con un URI che il client considera autorevole. Se il server non desidera accettare la richiesta, DOVREBBE produrre un codice di stato 421 (Misdirected Request), che causerà al client di riprovare la richiesta.
Se il client scopre che la connessione che sta tentando di riutilizzare non è più disponibile, PUÒ riprovare una richiesta non sicura su una nuova connessione.
Un proxy PUÒ riutilizzare le connessioni allo stesso server di origine.
9.1.2. The 421 (Misdirected Request) Status Code (Il Codice di Stato 421 (Richiesta Mal Diretta))
Il codice di stato 421 (Misdirected Request) indica che la richiesta è stata diretta a un server che non è in grado di produrre una risposta. Questo può essere inviato da un server che non è configurato per produrre risposte per la combinazione di schema e autorità inclusa nell'URI della richiesta.
I client che ricevono una risposta 421 (Misdirected Request) POSSONO riprovare la richiesta, indipendentemente dal fatto che il metodo di richiesta sia idempotente o meno, su una connessione diversa. Questo è possibile perché è consentito generare un codice di risposta 421 solo prima che il server scelga di non fornire una risposta autorevole.
Questo codice di stato NON DEVE essere generato dai proxy. Una risposta 421 è memorizzabile nella cache; è euristica memorizzabile nella cache per impostazione predefinita a meno che non sia indicato diversamente nella risposta (vedere Sezione 4.2.2 di [HTTP-CACHING]).
9.2. Use of TLS Features (Uso delle Funzionalità TLS)
Le implementazioni di HTTP/2 DEVONO utilizzare TLS versione 1.2 [TLS12] o superiore per gli URI "https". Le indicazioni generali sull'uso delle implementazioni TLS sono fornite in [TLSBCP].
Le implementazioni di TLS DEVONO supportare l'estensione Server Name Indication (SNI) [TLS-EXT]. I client HTTP/2 DEVONO indicare il nome di dominio target durante l'handshake TLS a meno che non sia fornito un meccanismo alternativo per indicare l'host target.
Le distribuzioni di HTTP/2 che dipendono da TLS 1.3 [TLS13] o superiore DOVREBBERO supportare e utilizzare l'estensione TLS Application-Layer Protocol Negotiation (ALPN) [TLS-ALPN] sia per i client che per i server. Ciò identifica l'uso di HTTP/2 durante l'handshake TLS senza consumare un round trip.
Mentre le opzioni a livello di connessione non sono specifiche per l'uso di HTTP, un server che utilizza HTTP/2 può trasmettere le sue preferenze per le connessioni. TLS fornisce crittografia, che può minimizzare la capacità degli intercettatori di apprendere informazioni scambiate tra un client e un server. TLS fornisce anche protezione dell'integrità, garantendo che le informazioni non siano modificate durante il transito, sia attraverso corruzione di rete involontaria sia attraverso attaccanti attivi.
Le regole della Sezione 7.4.1.4 di [TLS12] DEVONO essere seguite dopo che l'uso di HTTP/2 è stato negoziato. Queste regole utilizzano il certificato del server per stabilire l'identità; i certificati client non possono essere utilizzati per questo scopo. Sono richiesti anche i controlli della catena di certificati e dell'autorità di certificazione (CA).
Se HTTP/2 è negoziato su TLS 1.2, DEVE essere offerta la lista nera delle suite di cifratura TLS 1.2 (Sezione 9.2.2).
L'uso di certificati TLS compressi è sconsigliato; i certificati utilizzati dai client e dai server in HTTP/2 NON DOVREBBERO essere compressi a meno che non sia esplicitamente richiesto dal client.
9.2.1. TLS 1.2 Features (Funzionalità TLS 1.2)
Questa sezione descrive le restrizioni sull'uso di TLS 1.2 specifiche per HTTP/2. Poiché queste restrizioni sono principalmente affrontate in TLS 1.3, le implementazioni sono incoraggiate a utilizzare TLS 1.3 o superiore. Le implementazioni che utilizzano solo TLS 1.2 DEVONO conformarsi ai requisiti di questa sezione.
9.2.1.1. TLS 1.2 Features for HTTP/2 Clients (Funzionalità TLS 1.2 per i Client HTTP/2)
Le implementazioni dei client HTTP/2 DEVONO supportare l'invio di TLS Server Name Indication (SNI) [TLS-EXT] attraverso il campo di estensione nell'handshake.
I client HTTP/2 DEVONO supportare TLS Application-Layer Protocol Negotiation (ALPN) [TLS-ALPN].
9.2.1.2. TLS 1.2 Features for HTTP/2 Servers (Funzionalità TLS 1.2 per i Server HTTP/2)
Se il server negozia HTTP/2 con mezzi diversi da ALPN o NPN, il server DEVE fornire al client un'opportunità di indicare se è disposto a utilizzare HTTP/2.
I server HTTP/2 DOVREBBERO inviare l'estensione extended master secret [RFC7627]. Se il client non supporta questa estensione, il server NON DEVE riprendere una sessione precedentemente stabilita. Se l'extended master secret è negoziato, il server PUÒ riprendere una sessione precedentemente stabilita.
9.2.2. TLS 1.2 Cipher Suites (Suite di Cifratura TLS 1.2)
Le distribuzioni di HTTP/2 su TLS 1.2 DEVONO supportare TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] con la curva ellittica secp256r1 [RFC8422]. Si noti che i client indicano il loro supporto per le curve che supportano tramite l'estensione supported_groups [TLS13] nel messaggio TLS ClientHello, e i server indicano il supporto per una curva selezionando una qualsiasi delle curve elencate che l'estensione offre.
I client POSSONO pubblicizzare il supporto di qualsiasi suite di cifratura su TLS 1.2 utilizzata con HTTP/2. Tuttavia, le suite di cifratura elencate di seguito hanno qualità note di scarsa qualità e sono quindi proibite per l'uso in HTTP/2 su TLS 1.2. Queste suite hanno una o più delle seguenti proprietà:
- Suite di cifratura NULL, che non forniscono crittografia.
- Suite basate su cifrari a flusso, il cui uso in TLS è vulnerabile agli attacchi.
- Suite basate su RC4, che hanno gravi problemi di sicurezza.
- Suite basate su 3DES, che forniscono meno di 112 bit di sicurezza effettiva.
- Suite di cifratura a blocchi in modalità CBC, che sono sensibili agli attacchi in TLS, in particolare in TLS 1.2 e versioni precedenti.
- Suite basate sullo scambio di chiavi RSA, che non forniscono forward secrecy.
- Suite che utilizzano parametri Diffie-Hellman sconsigliati per l'uso con TLS.
- Suite che utilizzano digest SHA-1 con scarso supporto per gli algoritmi AEAD.
Un elenco completo delle suite di cifratura proibite è fornito nell'Appendice A.
9.3. Connection Preface (Prefazione della Connessione)
In HTTP/2, ogni endpoint è tenuto a inviare una prefazione della connessione come conferma finale del protocollo in uso e per stabilire le impostazioni iniziali per la connessione HTTP/2. Il client e il server inviano ciascuno una prefazione della connessione diversa.
La prefazione della connessione client inizia con una sequenza di 24 ottetti, che in notazione esadecimale è:
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
Cioè, la prefazione della connessione inizia con la stringa PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n. Questa sequenza DEVE essere seguita da un frame SETTINGS (Sezione 6.5), che PUÒ essere vuoto. Il client invia la prefazione della connessione client immediatamente dopo aver ricevuto la prefazione della connessione server.
| Nota: La prefazione della connessione client è selezionata in modo tale da minimizzare | la possibilità che una connessione HTTP/2 sia vista come una richiesta HTTP/1.1 valida da | server che elaborano altri protocolli HTTP. Si noti che nessuna richiesta HTTP/1.1 può | ragionevolmente includere "PRI" come token del metodo.
La prefazione della connessione server consiste in un frame SETTINGS potenzialmente vuoto (Sezione 6.5) che DEVE essere il primo frame che il server invia nella connessione HTTP/2.
Un client che sta effettuando l'upgrade avendo ricevuto una risposta 101 (Switching Protocols) che richiede HTTP/1.1 (o precedente) DEVE inviare immediatamente la prefazione della connessione client.
Il server riceve la prefazione della connessione client e il client riceve la prefazione della connessione server. Il frame SETTINGS nella prefazione della connessione DEVE essere riconosciuto (vedere Sezione 6.5.3) come parte dell'ulteriore stabilimento della connessione (vedere Sezione 3.4).
Per evitare latenze inutili, ai client è consentito inviare frame aggiuntivi al server immediatamente dopo l'invio della prefazione della connessione client, senza attendere di ricevere la prefazione della connessione server. È importante notare, tuttavia, che il frame SETTINGS della prefazione della connessione server potrebbe includere parametri che devono essere onorati per comunicare con il server. Alla ricezione del frame SETTINGS, il client DOVREBBE onorare tutti i parametri stabiliti. In alcune configurazioni, è possibile che il server trasmetta SETTINGS prima che il client invii frame aggiuntivi, fornendo un'opportunità per evitare questo problema.
I client e i server DEVONO trattare una prefazione della connessione non valida come un errore di connessione (Sezione 5.4.1) di tipo PROTOCOL_ERROR. Un frame GOAWAY (Sezione 6.8) PUÒ essere omesso in questo caso, poiché una prefazione non valida indica che il peer non sta utilizzando HTTP/2.
Capitolo 9 completato!
References
- [TCP] RFC 793
- [TLS13] RFC 8446
- [TLS12] RFC 5246
- [TLS-EXT] RFC 6066
- [TLS-ALPN] RFC 7301
- [TLSBCP] RFC 9325
- [TLS-ECDHE] RFC 5289
- [RFC8422] RFC 8422
- [RFC7627] RFC 7627
- [ALT-SVC] RFC 7838
- [HTTP-CACHING] RFC 9111