El domain fronting no és una VPN: dos noms, una petició
Dos noms en una sola petició HTTPS no són un túnel. El fronting depèn de les regles d’encaminament del proveïdor; una VPN tria quins paquets viatgen. Dibuixa’ls per separat.
Les dues tècniques s’arxivin juntes perquè totes dues impliquen un intermediari i totes dues sonen a amagar. Operen sobre objectes diferents. El domain fronting tracta de quin nom apareix en quina capa d’una petició HTTPS. Una VPN tracta de quins paquets segueixen un camí concret fins a un parell. Anomenar el fronting una mena de VPN porta a dissenys que no poden funcionar i a revisions que fan la pregunta equivocada.
Dos noms, dues capes
Una connexió TLS pot portar un nom de servidor al seu handshake. Un cop la connexió existeix, la petició HTTP identifica l’autoritat que vol, normalment a la capçalera Host. Són dos camps llegits en dos moments diferents per dues peces de programari diferents.
| 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 |
El domain fronting aprofita una diferència entre els dos primers perquè un servei de fronting accepti la connexió i després encamini la petició a un altre lloc. Només funciona on aquell servei està disposat a encaminar-la, cosa que és una qüestió de política del proveïdor i no un truc de protocol.
El fronting depèn del proveïdor, no de la tècnica
Com a exemple acotat, la guia Front Door FAQ d’Azure documenta les proteccions contra el domain fronting. Descriu una discrepància permesa per a dominis dins de la mateixa subscripció i rutes configurades, i una resposta 421 Misdirected Request quan la protecció de discrepància bloqueja una petició.
Aquesta única política documentada tomba tots dos eslògans alhora. No tota parella de noms diferents funciona, i no tota discrepància està prohibida. Altres serveis tenen les seves pròpies comprovacions, els seus propis requisits de desplegament i els seus propis codis d’error.
Tampoc no és una instrucció per saltar-se les restriccions d’una altra xarxa. Llegir les regles d’encaminament d’un proveïdor per entendre què permet és feina d’arquitectura; tractar aquestes regles com una recepta d’evasió és una activitat diferent amb conseqüències diferents. Mantingues les dues activitats separades al document que escrius. La segona és el que fa que un disseny sigui rebutjat en una revisió.
Què tria realment una VPN
En una VPN de xarxa, l’encaminament i la política de plataforma seleccionen el trànsit intern per a un túnel fins a un parell. Segons el disseny, això pot cobrir diverses aplicacions o un subconjunt definit, i pot transportar protocols que no tenen cap petició HTTP.
El fronting no fa res d’això. Organitzar una petició HTTPS a través d’un servei de fronting no instal·la cap ruta de xarxa privada, no transporta aplicacions UDP arbitràries i no fa que tots els programes del dispositiu utilitzin el servei. Si necessites aquesta cobertura, necessites un proxy o un túnel, no un truc de noms.
És per això que les dues es confonen en la revisió: totes dues es descriuen com a intermediaris i totes dues apareixen en documents sobre accés. La interfície que ofereix cadascuna és completament diferent, i només una és un camí de xarxa.
La visibilitat no és binària
Ni la comparació és simplement ocult contra visible. Les consultes DNS, les adreces de destinació, les característiques del handshake, les mides dels paquets i el temps romanen observables per a qui estigui en posició de veure’ls, i el que aquell observador aprèn depèn d’on és.
Les dades de l’aplicació també són visibles als extrems que les acaben. Un servei de fronting que encamina la teva petició és un d’aquests extrems, i un parell de VPN és un altre. Cap de les dues disposicions no fa el contingut opac per a la part que l’ha de llegir per servir-te.
Dibuixa les tres caixes
Per a una revisió d’arquitectura, dibuixa l’extrem TLS, el servei d’encaminament HTTP i l’aplicació final com tres caixes separades, i després dibuixa qualsevol parell de VPN en un altre lloc. El lloc que tria una destinació web i el lloc que transporta paquets de xarxa privada no cal que siguin el mateix sistema, i normalment no ho són.
Un cop les caixes estan separades, les preguntes es poden respondre: quins noms accepta aquest proveïdor, quins protocols necessiten transport i quina part pot veure què. Un diagrama que les fusiona produeix un disseny que ningú no pot implementar i una revisió que discuteix sobre vocabulari.