Domain fronting är inte ett VPN: två namn, en förfrågan

De två teknikerna hamnar i samma fack eftersom båda involverar en mellanhand och båda låter som att dölja. De arbetar på olika objekt. Domain fronting handlar om vilket namn som syns på vilket lager i en HTTPS-förfrågan. Ett VPN handlar om vilka paket som tar en viss väg till en peer. Att kalla fronting för ett slags VPN leder till konstruktioner som inte kan fungera och till granskningar som ställer fel fråga.

Två namn, två lager

En TLS-anslutning kan bära ett servernamn i sin handskakning. När anslutningen finns identifierar HTTP-förfrågan den auktoritet den vill ha, vanligtvis i Host-headern. Det är två fält som läses vid två olika tillfällen av två olika programvarudelar.

Domain fronting utnyttjar en skillnad mellan de två första så att en fronting-tjänst accepterar anslutningen och sedan dirigerar förfrågan någon annanstans. Det fungerar bara där tjänsten är villig att dirigera den, vilket är en fråga om leverantörens policy och inte ett protokolltrick.

Fronting beror på leverantören, inte på tekniken

Som ett avgränsat exempel dokumenterar Front Door FAQ från Azure skydd mot domain fronting. Den beskriver en tillåten avvikelse för domäner inom samma prenumeration och konfigurerade rutter, och ett 421 Misdirected Request-svar när avvikelseskyddet blockerar en förfrågan.

Den enda dokumenterade policyn slår ner båda slagorden på en gång. Inte varje par av olika namn fungerar, och inte varje avvikelse är förbjuden. Andra tjänster har egna kontroller, egna distributionskrav och egna felkoder.

Det är inte heller en instruktion för att kringgå ett annat nätverks begränsningar. Att läsa en leverantörs routingregler för att förstå vad den tillåter är arkitekturarbete; att behandla reglerna som ett kringgåenderecept är en annan aktivitet med andra konsekvenser. Håll de två aktiviteterna åtskilda i dokumentet du skriver. Det är den andra som gör att en design avvisas i granskning.

Vad ett VPN faktiskt väljer

I ett nätverks-VPN väljer routing och plattformspolicy den inre trafiken för en tunnel till en peer. Beroende på upplägget kan det täcka flera applikationer eller en definierad delmängd, och det kan bära protokoll som inte har någon HTTP-förfrågan alls.

Fronting gör inget av detta. Att ordna en HTTPS-förfrågan via en fronting-tjänst installerar ingen privat nätverksrutt, bär inga godtyckliga UDP-applikationer och får inte varje program på enheten att använda tjänsten. Om du behöver den täckningen behöver du en proxy eller en tunnel, inte ett namntrick.

Det är därför de två förväxlas i granskning: båda beskrivs som mellanhänder, och båda förekommer i dokument om åtkomst. Gränssnittet som var och en erbjuder är helt olika, och bara en av dem är en nätverksväg.

Synlighet är inte binärt

Jämförelsen är inte heller bara dolt mot synligt. DNS-frågor, destinationsadresser, handskakningsegenskaper, paketstorlekar och tidsstämpling är alla observerbara för den som är positionerad att se dem, och vad den observatören lär sig beror på var den sitter.

Applikationsdata är också synliga vid de ändpunkter som avslutar dem. En fronting-tjänst som dirigerar din förfrågan är en av dessa ändpunkter, och en VPN-peer är en annan. Ingen av uppläggen gör innehållet ogenomskinligt för den part som måste läsa det för att betjäna dig.

Rita de tre lådorna

För en arkitekturgranskning, rita TLS-ändpunkten, HTTP-routingtjänsten och den slutliga applikationen som tre separata lådor, och rita sedan vilken VPN-peer som helst någon annanstans igen. Platsen som väljer ett webbmål och platsen som transporterar paket för ett privat nätverk behöver inte vara samma system, och är det vanligtvis inte.

När lådorna är åtskilda blir frågorna besvarbara: vilka namn accepterar den här leverantören, vilka protokoll behöver transport, och vilken part kan se vad. Ett diagram som smälter samman dem ger en design som ingen kan implementera och en granskning som grälar om ordförråd.