Domain Fronting ist kein VPN: zwei Namen, eine Anfrage
Zwei Namen in einer HTTPS-Anfrage sind kein Tunnel. Fronting hängt von den Routingregeln des Anbieters ab; ein VPN wählt aus, welche Pakete reisen. Zeichnen Sie beides getrennt.
Die beiden Techniken landen in derselben Schublade, weil beide einen Vermittler einbeziehen und beide nach Verbergen klingen. Sie arbeiten an unterschiedlichen Objekten. Domain Fronting dreht sich darum, welcher Name auf welcher Ebene einer HTTPS-Anfrage erscheint. Ein VPN dreht sich darum, welche Pakete einen bestimmten Weg zu einem Peer nehmen. Fronting eine Art VPN zu nennen führt zu Entwürfen, die nicht funktionieren können, und zu Reviews, die die falsche Frage stellen.
Zwei Namen, zwei Ebenen
Eine TLS-Verbindung kann in ihrem Handshake einen Servernamen mitführen. Sobald die Verbindung besteht, benennt die HTTP-Anfrage die Autorität, die sie will, üblicherweise im Host-Header. Das sind zwei Felder, die zu zwei verschiedenen Zeitpunkten von zwei verschiedenen Softwareteilen gelesen werden.
| 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 nutzt eine Differenz zwischen den ersten beiden aus, sodass ein Fronting-Dienst die Verbindung annimmt und die Anfrage dann woandershin leitet. Es funktioniert nur dort, wo dieser Dienst bereit ist, sie zu leiten, und das ist eine Frage der Anbieterrichtlinie und nicht eines Protokolltricks.
Fronting hängt vom Anbieter ab, nicht von der Technik
Als begrenztes Beispiel dokumentiert Front Door FAQ von Azure den Schutz vor Domain Fronting. Es beschreibt eine erlaubte Abweichung für Domains innerhalb desselben Abonnements und konfigurierter Routen sowie eine 421 Misdirected Request-Antwort, wenn der Schutz vor Abweichungen eine Anfrage blockiert.
Diese eine dokumentierte Richtlinie entkräftet beide Slogans auf einmal. Nicht jedes Paar unterschiedlicher Namen funktioniert, und nicht jede Abweichung ist verboten. Andere Dienste haben ihre eigenen Prüfungen, ihre eigenen Bereitstellungsanforderungen und ihre eigenen Fehlercodes.
Es ist auch keine Anleitung, die Beschränkungen eines anderen Netzes zu umgehen. Die Routingregeln eines Anbieters zu lesen, um zu verstehen, was er erlaubt, ist Architekturarbeit; diese Regeln als Umgehungsrezept zu behandeln ist eine andere Tätigkeit mit anderen Folgen. Halten Sie diese beiden Tätigkeiten in dem Dokument, das Sie schreiben, getrennt. Die zweite ist die, wegen der ein Entwurf im Review abgelehnt wird.
Was ein VPN tatsächlich auswählt
In einem Netzwerk-VPN wählen Routing und Plattformrichtlinie den inneren Verkehr für einen Tunnel zu einem Peer aus. Je nach Anordnung kann das mehrere Anwendungen oder eine definierte Teilmenge abdecken, und es kann Protokolle tragen, die überhaupt keine HTTP-Anfrage haben.
Fronting tut nichts davon. Eine HTTPS-Anfrage über einen Fronting-Dienst abzuwickeln installiert keine Route in ein privates Netz, trägt keine beliebigen UDP-Anwendungen und bringt nicht jedes Programm auf dem Gerät dazu, den Dienst zu nutzen. Wenn Sie diese Abdeckung brauchen, brauchen Sie einen Proxy oder einen Tunnel, keinen Namenstrick.
Deshalb werden die beiden im Review verwechselt: Beide werden als Vermittler beschrieben, und beide tauchen in Dokumenten über Zugriff auf. Die Schnittstelle, die jede bietet, ist völlig unterschiedlich, und nur eine von ihnen ist ein Netzwerkpfad.
Sichtbarkeit ist nicht binär
Der Vergleich ist auch nicht einfach verborgen gegen sichtbar. DNS-Abfragen, Zieladressen, Handshake-Merkmale, Paketgrößen und Timing bleiben alle für jemanden beobachtbar, der so positioniert ist, dass er sie sieht, und was dieser Beobachter lernt, hängt davon ab, wo er sitzt.
Anwendungsdaten sind auch an den Endpunkten sichtbar, die sie beenden. Ein Fronting-Dienst, der Ihre Anfrage leitet, ist einer dieser Endpunkte, und ein VPN-Peer ein anderer. Keine der beiden Anordnungen macht den Inhalt undurchsichtig für die Partei, die ihn lesen muss, um Sie zu bedienen.
Zeichnen Sie die drei Kästen
Zeichnen Sie für ein Architektur-Review den TLS-Endpunkt, den HTTP-Routingdienst und die endgültige Anwendung als drei getrennte Kästen und zeichnen Sie dann jeden VPN-Peer noch einmal woanders. Der Ort, der ein Webziel auswählt, und der Ort, der Pakete eines privaten Netzes transportiert, müssen nicht dasselbe System sein, und sind es meistens nicht.
Sobald die Kästen getrennt sind, werden die Fragen beantwortbar: Welche Namen akzeptiert dieser Anbieter, welche Protokolle brauchen Beförderung und welche Partei kann was sehen. Ein Diagramm, das sie verschmilzt, erzeugt einen Entwurf, den niemand umsetzen kann, und ein Review, das über Vokabular streitet.