Domain fronting er ikkje ein VPN: to namn, éin førespurnad

Dei to teknikkane blir arkiverte saman fordi begge involverer ein mellommann, og begge høyrest ut som skjuling. Dei arbeider på ulike objekt. Domain fronting handlar om kva namn som viser seg på kva lag i éin HTTPS-førespurnad. Ein VPN handlar om kva pakkar som tek ein bestemd veg til ein peer. Å kalle fronting ein slags VPN fører til design som ikkje kan fungere, og til gjennomgangar som stiller feil spørsmål.

To namn, to lag

Ei TLS-tilkopling kan bera eit servernamn i handtrykket sitt. Når tilkoplinga finst, identifiserer HTTP-førespurnaden den autoriteten han vil ha, vanlegvis i Host-headeren. Det er to felt som blir lesne på to ulike tidspunkt av to ulike programvaredelar.

Domain fronting utnyttar ein skilnad mellom dei to første, slik at ein fronting-teneste godtek tilkoplinga og deretter ruter førespurnaden ein annan stad. Det verkar berre der tenesta er viljug til å rute han, og det er eit spørsmål om leverandørpolitikk og ikkje eit protokolltriks.

Fronting er avhengig av leverandøren, ikkje av teknikken

Som eit avgrensa døme dokumenterer Front Door FAQ frå Azure vern mot domain fronting. Han skildrar ein tillaten usemje for domene innanfor same abonnement og konfigurerte ruter, og eit 421 Misdirected Request-svar når vernet mot usemje blokkerer ein førespurnad.

Den eine dokumenterte policyen slår ned begge slagorda på ein gong. Ikkje kvart par av ulike namn verkar, og ikkje kvar usemje er forboden. Andre tenester har sine eigne kontrollar, sine eigne distribusjonskrav og sine eigne feilkodar.

Det er heller ikkje ein instruksjon for å omgå avgrensingane til eit anna nettverk. Å lese rutereglane til ein leverandør for å forstå kva han tillèt er arkitekturarbeid; å handsame reglane som ein omgåingsoppskrift er ein annan aktivitet med andre følgjer. Hald dei to aktivitetane frå kvarandre i dokumentet du skriv. Det er den andre som gjer at eit design blir avvist i gjennomgang.

Kva ein VPN faktisk vel

I ein nettverks-VPN vel ruting og plattformpolitikk den indre trafikken for ein tunnel til ein peer. Avhengig av ordninga kan det dekkje fleire applikasjonar eller ei definert delmengd, og det kan bera protokollar som ikkje har nokon HTTP-førespurnad i det heile.

Fronting gjer ingenting av dette. Å arrangere éin HTTPS-førespurnad gjennom ein fronting-teneste installerer ikkje ei privat nettverksrute, ber ikkje vilkårlege UDP-applikasjonar og får ikkje kvart program på eininga til å bruke tenesta. Viss du treng den dekninga, treng du ein proxy eller ein tunnel, ikkje eit navnetriks.

Det er derfor dei to blir forveksla i gjennomgang: begge blir skildra som mellommann, og begge førekjem i dokument om tilgang. Grensesnittet kvar av dei tilbyr er heilt ulikt, og berre éin av dei er ein nettverksveg.

Synlegheit er ikkje binært

Samanlikninga er heller ikkje berre skjult mot synleg. DNS-spørjingar, destinasjonsadresser, handtrykkseigenskapar, pakkestorleikar og tidsbruk er alle observerbare for nokon som er plassert slik at dei kan sjå dei, og kva den observatøren lærer er avhengig av kvar dei sit.

Applikasjonsdata er også synlege ved endepunkta som avsluttar dei. Ein fronting-teneste som ruter førespurnaden din er eitt av desse endepunkta, og ein VPN-peer er eit anna. Ingen av ordningane gjer innhaldet ugjennomsiktig for parten som må lese det for å tene deg.

Teikn dei tre boksane

For ein arkitekturgjennomgang, teikn TLS-endepunktet, HTTP-rutetenesta og den endelege applikasjonen som tre separate boksar, og teikn deretter kvar VPN-peer ein annan stad igjen. Staden som vel eit webmål og staden som transporterer pakkar for eit privat nettverk treng ikkje å vere same system, og er det vanlegvis ikkje.

Når boksane er skilde, blir spørsmåla svarable: kva namn godtek denne leverandøren, kva protokollar treng transport, og kva part kan sjå kva. Eit diagram som smeltar dei saman gir eit design ingen kan implementere, og ein gjennomgang som kranglar om ordtilfang.