Domain fronting - vysvětlení rozdílu dvou typů

Domain fronting - vysvětlení rozdílu dvou typů
« kdy: 24. 09. 2021, 15:07:12 »
Kdo je znalý domain fronting,uměl by vysvětlit v článku rozdíl v serverech "n services that do not automatically forward requests" a těmi co  dělají "forwards the request to the domain found" (nazývanými pull). ( Plný text dole)

Nějak jsem nepochytil rozdíl mezi servery lišící se touto vlastností (v druhém odstavci je popsán druhý typ). A potažmo, proč pro první typ není potřeba "reflector". Je tam uveden jako příklad druhého typu appspot.com. Jaký by byl příklad prvního?

Nebo je to nějak tak, že v jednom případě rovnou mohu službu deploynout na jednu doménu uvnitř poskytovatele cloudu, zatímco u druhé služba běžet nemůže a musí tam být "reflector", který přeposílá komunikaci někam jinam?

A do třetice, proč to nazývají "pull" strategií / typem.?


https://www.bamsoftware.com/papers/fronting/ (pro ty 2 odstavce stačí vyhledat  slovo pull na stránce)

Citace
Domain fronting works with CDNs because a CDN’s frontend server (called an “edge server”), on receiving a request for a resource not already cached, forwards the request to the domain found in the Host header (the “origin server”). (There are other ways CDNs may work, but this “origin pull” configuration is common.) The client issues a request that appears to be destined for an unrelated front domain, which may be any of the CDN’s domains that resolve to an edge server; this fronted request is what the censor sees. The edge server decrypts the request, reads the Host header and forwards the request to the specified origin, which in the circumvention scenario is a general-purpose proxy. The origin server, being a proxy, would be blocked by the censor if accessed directly—fronting hides its address from the censor.

On services that do not automatically forward requests, it is usually possible to install a trivial “reflector” web application that emulates an origin-pull CDN. In this case, fronting does not protect the address of the origin per se; rather it protects the address of the reflector application, which in turn forwards requests to the origin. Google App Engine is an example of such a service: against a censor that blocks the App Engine domain appspot.com but allows other Google domains, domain fronting enables access to a reflector running on appspot.com.
« Poslední změna: 24. 09. 2021, 15:39:36 od Petr Krčmář »


Re:Domain fronting - vysvětlení rozdílu dvou typů
« Odpověď #1 kdy: 24. 09. 2021, 16:22:57 »
V obou případech klient komunikuje za sítě, kde je cenzura, s CDN, a v SNI hlavičce pošle název nějakého zdroje umístěného v dané CDN, který je z pohledu cenzora v pořádku. Zároveň klient spoléhá na to, že CDN nebude kontrolovat shodu SNI názvu a domény uvedené v HTTP hlavičce Host.

Typ popsaný v prvním odstavci funguje tak, že v hlavičce Host pošle rovnou doménové jméno cílového (cenzurovaného) serveru. Takže třeba v SNI je název encyklopedie-marxismu-leninismu.cn, ale v Host je hk.wikipeida.org. Pokud CDN nekontroluje, zda má obsluhovat doménu hk.wikipeida.org (funguje vlastně jako otevřená proxy – zajímalo by mne, zda tak nějaká používaná CDN opravdu funguje), pošle sama dotaz na webserver hk.wikipeida.org, nakešuje výsledek a vrátí ho klientovi.

Reflektor v tomhle případě není potřeba proto, že CDN neověřuje, jestli doména požadovaná klientem v hlavičce Host je zákazník dané CDN. Pravděpodobně spoléhá na to, že k tomuhle ověření došlo už na základě SNI – pokud doména v SNI není zákazníkem CDN, nemá pro ni CDN certifikát a tím pádem normální HTTPS klient nenaváže spojení.

Pokud CDN nefunguje jako otevřená proxy, tohle by nefungovalo – CDN by na dotaz na doménu hk.wikipeida.org odpověděla, že takovou adresu nezná. Pak se může použít druhá varianta, že se do komunikace přidá ještě reflektor. Ten obsluhuje nějakou doménu, která je regulérně hostovaná v té CDN, takže třeba my-hk-wikipedia.eu. Klient pak v Host hlavičce musí poslat tuhle speciální doménu, CDN se dotáže reflektoru na příslušnou stránku – a reflektor se zeptá na stejnou cestu ale v doméně hk.wikipeida.org. Tj. reflektor vlastně vytvoří duplikát webu na jiné webové adrese. Kdyby se používala přímo tahle adresa, cenzor ji také zablokuje, ale tím, že to jde přes CDN a v SNI je jiná doména, cenzor nezjistí, o jaký požadavek se jedná. A ta speciální adresa naopak zajistí, že si ji můžete „povolit“ na CDN. Reflektor je tam tedy potřeba z toho důvodu, pokud CDN kontroluje, že stahuje obsah jenom od svých zákazníků, a zároveň nemůžete zařídit, aby cílový web byl (třeba alespoň na oko) zákazníkem dané CDN.

Re:Domain fronting -důvod zrušení
« Odpověď #2 kdy: 01. 04. 2022, 17:50:22 »
nevíte, proč byl domain fronting zrušen ?  (víceméně v období dvou let ho zrušili klíčoví hráči big 5) (Microsoft-Akamai,, Google Cloud)

Nebylo no za základě jistých politicko-byznosových tlaků? Jsou vůbec služby googlu před tou dobou (2018) a po ní dostupné v číně a jakém rozsahu (vůbec/modifikované pro "specifický trh"/ v globální podobě)

https://www.root.cz/clanky/google-blokuje-domain-fronting-ztizil-tim-situaci-cenzurovanym-sluzbam/
https://www.root.cz/clanky/google-blokuje-domain-fronting-ztizil-tim-situaci-cenzurovanym-sluzbam/

Re:Domain fronting -důvod zrušení
« Odpověď #3 kdy: 02. 04. 2022, 23:04:45 »
nevíte, proč byl domain fronting zrušen ?  (víceméně v období dvou let ho zrušili klíčoví hráči big 5) (Microsoft-Akamai,, Google Cloud)
Viac krajin zacalo blokovat niektore domeny a nezaujimal ich collateral damage. Povodna architektura Googlu umoznovala request s google.com SNI, pricom realne isiel dotaz na cloud.
Velki hraci sa zlakli blokovania a straty postavenia v takychto rezimoch a radsej zablokoval domain fronting.

Re:Domain fronting - vysvětlení rozdílu dvou typů
« Odpověď #4 kdy: 03. 04. 2022, 15:24:25 »
Zajímavé, já dosud myslel, že domain fronting popisuje trochu jiný scénář. IIRC je totiž nutné použít doménu hostovanou na téže CDN. Tím, že se pošle v SNI jiné doménové jméno, CDN pošle zpátky samozřejmě odpovídající certifikát. (Díky tomu, že i doména uvedená v SNI je hostovaná v této CDN, je možné naservírovat platný certifikát.) Klient ale ví, že má tento certifikát očekávat, tak ho akceptuje. (Nechávám teď stranou, jak zabránit zneužití držitelem domény, kterou uvádíme v SNI.) Jakmile je ale navázáno TLS spojení, klient pošle v hlavičce Host jméno domény, která ho skutečně zajímá.

Dává mi to takto více smysl. Nepředpokládá to, že provozovatel CDN dělá se facto univerzální proxy. Jen ti předpokládá, že po odeslání certifikátu již server nezajímá, či mu přišlo v SNI. Což mi přijde mnohem uvěřitelnější.


Re:Domain fronting - vysvětlení rozdílu dvou typů
« Odpověď #5 kdy: 03. 04. 2022, 16:00:45 »
Zajímavé, já dosud myslel, že domain fronting popisuje trochu jiný scénář.
To co popisujete přece jeden z dvou popsaných scénářů (ten pravděpodobnější).

Re:Domain fronting - vysvětlení rozdílu dvou typů
« Odpověď #6 kdy: 03. 04. 2022, 21:23:32 »
OK, asi jsem špatně četl.