9. Considerazioni sulla sicurezza
9.1. Cambio di porte
L'uso di un servizio alternativo implica l'accesso alle risorse di un'origine su una porta alternativa, come minimo. Pertanto, un attaccante in grado di iniettare servizi alternativi e di ascoltare sulla porta pubblicizzata è in grado di dirottare un'origine. Su alcuni server, è normale che gli utenti possano controllare alcune pagine personali disponibili su una porta condivisa e anche accettare richieste su porte meno privilegiate.
Ad esempio, un attaccante in grado di aggiungere campi di intestazione di risposta HTTP ad alcune pagine può reindirizzare il traffico per un'intera origine a una porta diversa sullo stesso host utilizzando il campo di intestazione Alt-Svc; se quella porta è sotto il controllo dell'attaccante, può farsi passare per il server HTTP.
Questo rischio è mitigato dai requisiti nella Sezione 2.1.
Sui server, questo rischio può anche essere ridotto limitando la capacità di pubblicizzare servizi alternativi e limitando chi può aprire una porta per l'ascolto su quell'host.
9.2. Cambio di host
Quando l'host viene modificato a causa dell'uso di un servizio alternativo, ciò presenta un'opportunità per gli attaccanti di dirottare la comunicazione verso un'origine.
Ad esempio, se un attaccante può convincere un agente utente a inviare tutto il traffico per "innocent.example.org" a "evil.example.com" associandolo con successo come servizio alternativo, può farsi passare per quell'origine. Questo può essere fatto localmente (vedere le mitigazioni nella Sezione 9.1) o in remoto (ad esempio, da un intermediario come attacco man-in-the-middle).
Questo è il motivo del requisito nella Sezione 2.1 secondo cui i client devono avere ragionevoli garanzie che il servizio alternativo sia sotto il controllo di e valido per l'intera origine; ad esempio, la presentazione di un certificato per l'origine dimostra che il servizio alternativo è autorizzato a servire il traffico per l'origine.
Si noti che questa garanzia è forte solo quanto il metodo utilizzato per autenticare il servizio alternativo. In particolare, quando viene utilizzata l'autenticazione TLS per farlo, esistono exploit ben noti per far sembrare legittimo il certificato di un attaccante.
I servizi alternativi potrebbero essere utilizzati per rendere persistente un tale attacco. Ad esempio, un intermediario potrebbe intercettare la comunicazione protetta da TLS verso un target, quindi indirizzare tutto il traffico verso un servizio alternativo con una lunga durata di freschezza in modo che l'agente utente continui a indirizzare il traffico all'attaccante anche quando non utilizza l'intermediario.
Le implementazioni DEVONO eseguire qualsiasi validazione di certificate pinning (come [RFC7469]) sui servizi alternativi proprio come farebbero sulle connessioni dirette all'origine. Le implementazioni possono anche scegliere di aggiungere altri requisiti su quali certificati sono accettabili per i servizi alternativi.
9.3. Cambio di protocolli
Quando il protocollo ALPN viene modificato a causa dell'uso di un servizio alternativo, le proprietà di sicurezza della nuova connessione all'origine possono essere diverse da quelle della connessione "normale" all'origine, poiché l'identificatore del protocollo stesso lo implica.
Ad esempio, se un URI "https://" pubblicizza un protocollo che non utilizza una qualche forma di crittografia end-to-end (molto probabilmente TLS), ciò viola le aspettative di sicurezza che lo schema URI implica. Pertanto, i client non possono utilizzare i servizi alternativi alla cieca, ma devono invece valutare l'opzione o le opzioni presentate per garantire che i requisiti di sicurezza e le aspettative delle specifiche, delle implementazioni e degli utenti finali siano soddisfatti.
9.4. Tracciamento dei client che utilizzano servizi alternativi
La scelta di un servizio alternativo implica la connessione a un nuovo nome host fornito dal server. Utilizzando nomi univoci, i server potrebbero concepibilmente tracciare le richieste dei client. Tale tracciamento potrebbe seguire gli utenti attraverso più reti, quando viene utilizzato il flag "persist".
I client che desiderano impedire la correlazione delle richieste possono decidere di non utilizzare servizi alternativi per più richieste che altrimenti non sarebbero autorizzate a essere correlate.
In un agente utente, qualsiasi informazione sul servizio alternativo DEVE essere rimossa quando vengono cancellati i dati specifici dell'origine (tipicamente, quando vengono cancellati i cookie [RFC6265]).
9.5. Confusione sullo schema della richiesta
Alcune applicazioni HTTP lato server fanno ipotesi sulla sicurezza basate sul contesto di connessione; ad esempio, equiparando l'essere serviti sulla porta 443 all'uso di un URI "https://" e alle varie proprietà di sicurezza che ciò implica.
Ciò influisce non solo sulle proprietà di sicurezza della connessione stessa, ma anche sullo stato del client dall'altra parte; ad esempio, un browser Web tratta gli URI "https://" in modo diverso dagli URI "http://" in molti modi, non solo ai fini della gestione del protocollo.
Poiché uno degli usi dei servizi alternativi è consentire la migrazione di una connessione a un protocollo e una porta diversi, queste applicazioni potrebbero confondersi sulle proprietà di sicurezza di una determinata connessione, inviando informazioni (ad esempio, cookie e contenuti) destinate a un contesto sicuro (come un URI "https://") a un client che non lo tratta come tale.
Questo rischio può essere mitigato nei server utilizzando lo schema URI esplicitamente trasportato dal protocollo (come ":scheme" in HTTP/2 o la "forma assoluta" del target della richiesta in HTTP/1.1) come indicazione del contesto di sicurezza, invece di altre proprietà di connessione ([RFC7540], Sezione 8.1.2.3 e [RFC7230], Sezione 5.3.2).
Quando il protocollo non trasporta esplicitamente lo schema (come è tipicamente il caso per HTTP/1.1 su TLS), i server possono mitigare questo rischio assumendo che tutte le richieste abbiano un contesto non sicuro o astenendosi dal pubblicizzare servizi alternativi per schemi non sicuri (ad esempio, HTTP).