Domain fronting is geen VPN: twee namen, één verzoek
Twee namen in één HTTPS-verzoek is geen tunnel. Fronting hangt af van de routeringsregels van de provider; een VPN kiest welke pakketten reizen. Teken ze apart.
De twee technieken worden samen gearchiveerd omdat beide een tussenpersoon hebben en beide als verbergen klinken. Ze werken op verschillende objecten. Domain fronting gaat over welke naam op welke laag van één HTTPS-verzoek verschijnt. Een VPN gaat over welke pakketten een bepaald pad naar een peer nemen. Fronting een soort VPN noemen leidt tot ontwerpen die niet kunnen werken, en tot beoordelingen die de verkeerde vraag stellen.
Twee namen, twee lagen
Een TLS-verbinding kan een servernaam in zijn handshake dragen. Zodra de verbinding bestaat, identificeert het HTTP-verzoek de autoriteit die het wil, meestal in de Host-header. Dat zijn twee velden die op twee verschillende momenten door twee verschillende stukken software worden gelezen.
| 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 maakt gebruik van een verschil tussen de eerste twee, zodat een frontingdienst de verbinding accepteert en het verzoek daarna eldersheen routeert. Het werkt alleen waar die dienst bereid is het te routeren, en dat is een kwestie van providerbeleid en niet van een protocoltruc.
Fronting hangt af van de provider, niet van de techniek
Als begrensd voorbeeld documenteert Front Door FAQ van Azure de bescherming tegen domain fronting. Het beschrijft een toegestane afwijking voor domeinen binnen hetzelfde abonnement en geconfigureerde routes, en een 421 Misdirected Request-antwoord wanneer de afwijkingsbescherming een verzoek blokkeert.
Dat ene gedocumenteerde beleid ontkracht beide slogans tegelijk. Niet elk paar verschillende namen werkt, en niet elke afwijking is verboden. Andere diensten hebben hun eigen controles, hun eigen implementatievereisten en hun eigen foutcodes.
Het is ook geen instructie om de beperkingen van een ander netwerk te omzeilen. De routeringsregels van een provider lezen om te begrijpen wat die toestaat is architectuurwerk; die regels als een omzeilingsrecept behandelen is een andere activiteit met andere gevolgen. Houd die twee activiteiten gescheiden in het document dat je schrijft. De tweede is degene waardoor een ontwerp in review wordt afgewezen.
Wat een VPN werkelijk selecteert
In een netwerk-VPN selecteren routering en platformbeleid het interne verkeer voor een tunnel naar een peer. Afhankelijk van de opstelling kan dat meerdere applicaties of een gedefinieerde subset dekken, en het kan protocollen vervoeren die helemaal geen HTTP-verzoek hebben.
Fronting doet niets daarvan. Eén HTTPS-verzoek via een frontingdienst regelen installeert geen privénetwerkroute, vervoert geen willekeurige UDP-applicaties en zorgt er niet voor dat elk programma op het apparaat de dienst gebruikt. Als je die dekking nodig hebt, heb je een proxy of een tunnel nodig, geen naamtruc.
Daarom worden de twee in review verward: beide worden als tussenpersoon beschreven, en beide komen voor in documenten over toegang. De interface die elk biedt is volledig verschillend, en slechts één ervan is een netwerkpad.
Zichtbaarheid is niet binair
De vergelijking is ook niet simpelweg verborgen tegenover zichtbaar. DNS-query's, bestemmingsadressen, handshakekenmerken, pakketgroottes en timing blijven allemaal waarneembaar voor wie gepositioneerd is om ze te zien, en wat die waarnemer leert hangt af van waar hij zit.
Applicatiegegevens zijn ook zichtbaar bij de eindpunten die ze beëindigen. Een frontingdienst die je verzoek routeert is een van die eindpunten, en een VPN-peer is een andere. Geen van beide opstellingen maakt de inhoud ondoorzichtig voor de partij die hem moet lezen om jou te bedienen.
Teken de drie dozen
Teken voor een architectuurreview het TLS-eindpunt, de HTTP-routeringsdienst en de uiteindelijke applicatie als drie afzonderlijke dozen, en teken daarna elke VPN-peer ergens anders opnieuw. De plek die een webbestemming kiest en de plek die pakketten van een privénetwerk vervoert hoeven niet hetzelfde systeem te zijn, en zijn dat meestal niet.
Zodra de dozen gescheiden zijn, worden de vragen beantwoordbaar: welke namen accepteert deze provider, welke protocollen hebben vervoer nodig, en welke partij kan wat zien. Een diagram dat ze samensmelt levert een ontwerp op dat niemand kan implementeren en een review die over woordenschat ruziet.