Domain fronting er ikke en VPN: to navn, én forespørsel

De to teknikkene arkiveres sammen fordi begge involverer en mellommann, og begge høres ut som skjuling. De arbeider på forskjellige objekter. Domain fronting handler om hvilket navn som vises på hvilket lag i én HTTPS-forespørsel. En VPN handler om hvilke pakker som tar en bestemt vei til en peer. Å kalle fronting en slags VPN fører til design som ikke kan fungere, og til gjennomganger som stiller feil spørsmål.

To navn, to lag

En TLS-tilkobling kan bære et servernavn i håndtrykket sitt. Når tilkoblingen finnes, identifiserer HTTP-forespørselen den autoriteten den vil ha, vanligvis i Host-headeren. Det er to felt som leses på to forskjellige tidspunkter av to forskjellige programvarebiter.

Domain fronting utnytter en forskjell mellom de to første, slik at en fronting-tjeneste godtar tilkoblingen og deretter ruter forespørselen et annet sted. Det virker bare der tjenesten er villig til å rute den, og det er et spørsmål om leverandørpolitikk og ikke et protokolltriks.

Fronting avhenger av leverandøren, ikke av teknikken

Som et avgrenset eksempel dokumenterer Front Door FAQ fra Azure beskyttelse mot domain fronting. Den beskriver en tillatt uoverensstemmelse for domener innenfor samme abonnement og konfigurerte ruter, og et 421 Misdirected Request-svar når beskyttelsen mot uoverensstemmelse blokkerer en forespørsel.

Den ene dokumenterte policyen slår ned begge slagordene på én gang. Ikke hvert par av forskjellige navn virker, og ikke enhver uoverensstemmelse er forbudt. Andre tjenester har sine egne kontroller, sine egne distribusjonskrav og sine egne feilkoder.

Det er heller ikke en instruksjon for å omgå en annen nettverks begrensninger. Å lese en leverandørs ruteregler for å forstå hva den tillater er arkitekturak, å behandle reglene som en omgåelsesoppskrift er en annen aktivitet med andre konsekvenser. Hold de to aktivitetene fra hverandre i dokumentet du skriver. Det er den andre som gjør at et design blir avvist i gjennomgang.

Hva en VPN faktisk velger

I en nettverks-VPN velger ruting og plattformpolitikk den indre trafikken for en tunnel til en peer. Avhengig av ordningen kan det dekke flere applikasjoner eller en definert delmengde, og det kan bære protokoller som ikke har noen HTTP-forespørsel i det hele tatt.

Fronting gjør ingenting av dette. Å arrangere én HTTPS-forespørsel gjennom en fronting-tjeneste installerer ikke en privat nettverksrute, bærer ikke vilkårlige UDP-applikasjoner og får ikke hvert program på enheten til å bruke tjenesten. Hvis du trenger den dekningen, trenger du en proxy eller en tunnel, ikke et navnetriks.

Det er derfor de to forveksles i gjennomgang: begge beskrives som mellommenn, og begge forekommer i dokumenter om tilgang. Grensesnittet hver av dem tilbyr er helt forskjellig, og bare én av dem er en nettverksvei.

Synlighet er ikke binært

Sammenligningen er heller ikke bare skjult mot synlig. DNS-spørringer, destinasjonsadresser, håndtrykksegenskaper, pakkestørrelser og tidtaking er alle observerbare for noen som er plassert slik at de kan se dem, og hva den observatøren lærer avhenger av hvor de sitter.

Applikasjonsdata er også synlige ved endepunktene som avslutter dem. En fronting-tjeneste som ruter forespørselen din er ett av disse endepunktene, og en VPN-peer er et annet. Ingen av ordningene gjør innholdet ugjennomsiktig for parten som må lese det for å betjene deg.

Tegn de tre boksene

For en arkitekturgjennomgang, tegn TLS-endepunktet, HTTP-rutetjenesten og den endelige applikasjonen som tre separate bokser, og tegn deretter enhver VPN-peer et annet sted igjen. Stedet som velger et webmål og stedet som transporterer pakker for et privat nettverk trenger ikke å være samme system, og er det vanligvis ikke.

Når boksene er adskilt, blir spørsmålene besvarbare: hvilke navn godtar denne leverandøren, hvilke protokoller trenger transport, og hvilken part kan se hva. Et diagram som smelter dem sammen gir et design ingen kan implementere, og en gjennomgang som krangler om ordforråd.