Il domain fronting non è una VPN: due nomi, una richiesta
Due nomi in un’unica richiesta HTTPS non sono un tunnel. Il fronting dipende dalle regole di instradamento del provider; una VPN sceglie quali pacchetti viaggiano. Disegnali separatamente.
Le due tecniche finiscono archiviate insieme perché entrambe coinvolgono un intermediario ed entrambe suonano come occultamento. Operano su oggetti diversi. Il domain fronting riguarda quale nome compare a quale livello di una richiesta HTTPS. Una VPN riguarda quali pacchetti seguono un certo percorso verso un peer. Chiamare il fronting una specie di VPN porta a progetti che non possono funzionare e a revisioni che pongono la domanda sbagliata.
Due nomi, due livelli
Una connessione TLS può portare un nome di server nel suo handshake. Una volta che la connessione esiste, la richiesta HTTP identifica l’autorità che vuole, di solito nell’intestazione Host. Sono due campi letti in due momenti diversi da due pezzi di software diversi.
| Layer | What carries the name | Who reads it |
|---|---|---|
| TLS handshake | Server name indication | The TLS terminator in front of the service |
| HTTP request | Authority or Host header | The routing layer that picks a backend |
| Network path | Destination address and port | Routers, and the VPN peer if one is in use |
Il domain fronting sfrutta una differenza tra i primi due perché un servizio di fronting accetti la connessione e poi instradi la richiesta altrove. Funziona solo dove quel servizio è disposto a instradarla, il che è una questione di politica del provider e non un trucco di protocollo.
Il fronting dipende dal provider, non dalla tecnica
Come esempio circoscritto, la guida Front Door FAQ di Azure documenta le protezioni contro il domain fronting. Descrive una mancata corrispondenza consentita per i domini all’interno della stessa sottoscrizione e delle route configurate, e una risposta 421 Misdirected Request quando la protezione contro la mancata corrispondenza blocca una richiesta.
Quella singola politica documentata smonta entrambi gli slogan in una volta. Non ogni coppia di nomi diversi funziona, e non ogni mancata corrispondenza è vietata. Altri servizi hanno i propri controlli, i propri requisiti di distribuzione e i propri codici di errore.
Non è nemmeno un’istruzione per aggirare le restrizioni di un’altra rete. Leggere le regole di instradamento di un provider per capire cosa consente è lavoro di architettura; trattare quelle regole come una ricetta di aggiramento è un’altra attività con altre conseguenze. Tieni separate le due attività nel documento che scrivi. È la seconda che fa respingere un progetto in revisione.
Che cosa seleziona davvero una VPN
In una VPN di rete, l’instradamento e la politica della piattaforma selezionano il traffico interno per un tunnel verso un peer. A seconda della disposizione questo può coprire diverse applicazioni o un sottoinsieme definito, e può trasportare protocolli che non hanno alcuna richiesta HTTP.
Il fronting non fa nulla di tutto ciò. Organizzare una richiesta HTTPS attraverso un servizio di fronting non installa una route di rete privata, non trasporta applicazioni UDP arbitrarie e non fa usare il servizio a ogni programma del dispositivo. Se ti serve quella copertura, ti serve un proxy o un tunnel, non un trucco di nomi.
Ecco perché i due si confondono in revisione: entrambi sono descritti come intermediari, ed entrambi compaiono in documenti sull’accesso. L’interfaccia che ciascuno offre è completamente diversa, e solo una delle due è un percorso di rete.
La visibilità non è binaria
Né il confronto è semplicemente nascosto contro visibile. Le query DNS, gli indirizzi di destinazione, le caratteristiche dell’handshake, le dimensioni dei pacchetti e la temporizzazione restano tutti osservabili da chi è nella posizione di vederli, e ciò che quell’osservatore impara dipende da dove si trova.
Anche i dati dell’applicazione sono visibili agli endpoint che li terminano. Un servizio di fronting che instrada la tua richiesta è uno di quegli endpoint, e un peer VPN è un altro. Nessuna delle due disposizioni rende il contenuto opaco alla parte che deve leggerlo per servirti.
Disegna le tre caselle
Per una revisione di architettura, disegna l’endpoint TLS, il servizio di instradamento HTTP e l’applicazione finale come tre caselle separate, poi disegna qualsiasi peer VPN da qualche altra parte. Il luogo che sceglie una destinazione web e il luogo che trasporta pacchetti di rete privata non devono essere lo stesso sistema, e di solito non lo sono.
Una volta separate le caselle, le domande diventano rispondibili: quali nomi accetta questo provider, quali protocolli hanno bisogno di trasporto e quale parte può vedere cosa. Un diagramma che le fonde produce un progetto che nessuno può realizzare e una revisione che discute di vocabolario.