Le domain fronting n’est pas un VPN : deux noms, une requête
Deux noms dans une seule requête HTTPS ne font pas un tunnel. Le fronting dépend des règles de routage du fournisseur ; un VPN choisit quels paquets circulent. Dessinez-les séparément.
Les deux techniques sont classées ensemble parce que toutes deux impliquent un intermédiaire et que toutes deux évoquent la dissimulation. Elles portent sur des objets différents. Le domain fronting concerne le nom qui apparaît à quelle couche d’une requête HTTPS. Un VPN concerne les paquets qui empruntent un chemin donné vers un pair. Appeler le fronting une sorte de VPN mène à des conceptions qui ne peuvent pas fonctionner et à des revues qui posent la mauvaise question.
Deux noms, deux couches
Une connexion TLS peut porter un nom de serveur dans sa poignée de main. Une fois la connexion établie, la requête HTTP identifie l’autorité qu’elle veut, généralement dans l’en-tête Host. Ce sont deux champs lus à deux moments différents par deux morceaux de logiciel différents.
| 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 |
Le domain fronting exploite une différence entre les deux premiers pour qu’un service de fronting accepte la connexion puis achemine la requête ailleurs. Il ne fonctionne que là où ce service accepte de l’acheminer, ce qui est une question de politique du fournisseur et non une astuce de protocole.
Le fronting dépend du fournisseur, pas de la technique
Comme exemple borné, le guide Front Door FAQ d’Azure documente les protections contre le domain fronting. Il décrit une incohérence autorisée pour les domaines d’un même abonnement et des itinéraires configurés, et une réponse 421 Misdirected Request lorsque la protection contre les incohérences bloque une requête.
Cette seule politique documentée ruine les deux slogans d’un coup. Toutes les paires de noms différents ne fonctionnent pas, et toutes les incohérences ne sont pas interdites non plus. Les autres services ont leurs propres contrôles, leurs propres exigences de déploiement et leurs propres codes d’erreur.
Ce n’est pas non plus une instruction pour contourner les restrictions d’un autre réseau. Lire les règles de routage d’un fournisseur pour comprendre ce qu’il autorise est un travail d’architecture ; traiter ces règles comme une recette de contournement est une autre activité avec d’autres conséquences. Gardez ces deux activités séparées dans le document que vous écrivez. C’est la seconde qui fait rejeter une conception en revue.
Ce qu’un VPN sélectionne réellement
Dans un VPN réseau, le routage et la politique de la plateforme sélectionnent le trafic interne pour un tunnel vers un pair. Selon l’arrangement, cela peut couvrir plusieurs applications ou un sous-ensemble défini, et cela peut transporter des protocoles qui n’ont aucune requête HTTP.
Le fronting ne fait rien de tout cela. Organiser une requête HTTPS à travers un service de fronting n’installe pas de route de réseau privé, ne transporte pas d’applications UDP arbitraires et ne fait pas utiliser le service par tous les programmes de l’appareil. Si vous avez besoin de cette couverture, il vous faut un proxy ou un tunnel, pas une astuce de nommage.
C’est pourquoi les deux sont confondus en revue : tous deux sont décrits comme des intermédiaires, et tous deux apparaissent dans des documents sur l’accès. L’interface que chacun offre est complètement différente, et un seul des deux est un chemin réseau.
La visibilité n’est pas binaire
La comparaison n’est pas non plus simplement caché contre visible. Les requêtes DNS, les adresses de destination, les caractéristiques de la poignée de main, la taille des paquets et le minutage restent tous observables par quiconque est placé pour les voir, et ce que cet observateur apprend dépend de l’endroit où il se trouve.
Les données applicatives sont aussi visibles aux extrémités qui les terminent. Un service de fronting qui achemine votre requête est l’une de ces extrémités, et un pair VPN en est une autre. Aucun des deux arrangements ne rend le contenu opaque à la partie qui doit le lire pour vous servir.
Dessinez les trois boîtes
Pour une revue d’architecture, dessinez l’extrémité TLS, le service de routage HTTP et l’application finale comme trois boîtes séparées, puis dessinez tout pair VPN ailleurs encore. L’endroit qui choisit une destination web et l’endroit qui transporte des paquets de réseau privé n’ont pas besoin d’être le même système, et ne le sont généralement pas.
Une fois les boîtes séparées, les questions deviennent répondables : quels noms ce fournisseur accepte-t-il, quels protocoles ont besoin d’être transportés et quelle partie peut voir quoi. Un schéma qui les fusionne produit une conception que personne ne peut mettre en œuvre et une revue qui se dispute sur le vocabulaire.