Domain fronting er ikke en VPN: to navne, én anmodning
To navne i én HTTPS-anmodning er ikke en tunnel. Fronting afhænger af udbyderens ruteningsregler; en VPN vælger, hvilke pakker der rejser. Tegn dem hver for sig.
De to teknikker bliver arkiveret sammen, fordi begge involverer en mellemmand, og begge lyder som at skjule. De arbejder på forskellige objekter. Domain fronting handler om, hvilket navn der optræder på hvilket lag i én HTTPS-anmodning. En VPN handler om, hvilke pakker der tager en bestemt vej til en peer. At kalde fronting for en slags VPN fører til designs, der ikke kan fungere, og til gennemgange, der stiller det forkerte spørgsmål.
To navne, to lag
En TLS-forbindelse kan bære et servernavn i sit handshake. Når forbindelsen findes, angiver HTTP-anmodningen den autoritet, den vil have, typisk i Host-headeren. Det er to felter, der læses på to forskellige tidspunkter af to forskellige stykker software.
| 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 |
Domain fronting udnytter en forskel mellem de to første, så en fronting-tjeneste accepterer forbindelsen og derefter ruter anmodningen et andet sted hen. Det virker kun, hvor tjenesten er villig til at rute den, og det er et spørgsmål om udbyderpolitik snarere end et protokol-trick.
Fronting afhænger af udbyderen, ikke af teknikken
Som et afgrænset eksempel dokumenterer Front Door FAQ fra Azure beskyttelse mod domain fronting. Den beskriver en tilladt uoverensstemmelse for domæner inden for det samme abonnement og konfigurerede ruter, og et 421 Misdirected Request-svar, når beskyttelsen mod uoverensstemmelse blokerer en anmodning.
Den ene dokumenterede politik slår begge slogans ned på én gang. Ikke hvert par af forskellige navne virker, og ikke enhver uoverensstemmelse er forbudt. Andre tjenester har deres egne kontroller, deres egne udrulningskrav og deres egne fejlkoder.
Det er heller ikke en instruktion i at omgå et andet netværks begrænsninger. At læse en udbyders ruteningsregler for at forstå, hvad den tillader, er arkitekturarbejde; at behandle reglerne som en omgåelsesopskrift er en anden aktivitet med andre konsekvenser. Hold de to aktiviteter adskilt i det dokument, du skriver. Det er den anden, der får et design afvist i gennemgang.
Hvad en VPN faktisk vælger
I en netværks-VPN vælger routing og platforms-politik den indre trafik til en tunnel til en peer. Afhængigt af arrangementet kan det dække flere applikationer eller en defineret delmængde, og det kan bære protokoller, der slet ikke har nogen HTTP-anmodning.
Fronting gør intet af det. At arrangere én HTTPS-anmodning gennem en fronting-tjeneste installerer ikke en privat netværksrute, bærer ikke vilkårlige UDP-applikationer og får ikke hvert program på enheden til at bruge tjenesten. Hvis du har brug for den dækning, har du brug for en proxy eller en tunnel, ikke et navnetrick.
Det er derfor, de to bliver forvekslet i gennemgang: begge beskrives som mellemmænd, og begge optræder i dokumenter om adgang. Den grænseflade, hver af dem tilbyder, er helt forskellig, og kun én af dem er en netværksvej.
Synlighed er ikke binær
Sammenligningen er heller ikke bare skjult mod synligt. DNS-forespørgsler, destinationsadresser, handshake-egenskaber, pakkestørrelser og timing forbliver alle observerbare for en person, der er placeret så de kan se dem, og hvad den observatør lærer, afhænger af, hvor de sidder.
Applikationsdata er også synlige ved de endepunkter, der afslutter dem. En fronting-tjeneste, der ruter din anmodning, er et af disse endepunkter, og en VPN-peer er et andet. Ingen af arrangementerne gør indholdet uigennemsigtigt for den part, der skal læse det for at betjene dig.
Tegn de tre kasser
Til en arkitekturgennemgang tegner du TLS-endepunktet, HTTP-rutetjenesten og den endelige applikation som tre separate kasser og tegner derefter enhver VPN-peer et andet sted igen. Det sted, der vælger en webdestination, og det sted, der transporterer private netværkspakker, behøver ikke være det samme system, og er det normalt ikke.
Når kasserne er adskilt, bliver spørgsmålene besvarlige: hvilke navne accepterer denne udbyder, hvilke protokoller skal bæres, og hvilken part kan se hvad. Et diagram, der smelter dem sammen, giver et design, ingen kan implementere, og en gennemgang, der skændes om ordforråd.