HTTPS, DoH, ECH und ein VPN verbergen Unterschiedliches
Jeder Mechanismus entfernt einen anderen Beobachter aus dem Pfad, und keiner entfernt alle. Vergleichen Sie, was geschützt ist, bevor Sie einen weiteren Tunnel hinzufügen.
Ein VPN zu einem Browser hinzuzufügen, der bereits HTTPS, DoH und ECH nutzt, stapelt nicht drei Schutzmaßnahmen zu einer; es ändert, wer in der Position ist, was zu beobachten. Jeder Mechanismus entfernt eine andere Partei aus einem anderen Austausch, und jeder lässt etwas zurück. Die nützliche Frage ist nicht, welcher am stärksten ist, sondern welchen Beobachter Sie entfernen wollen, denn die Antwort entscheidet, ob ein Tunnel überhaupt hilft. Ein Vergleich der verbleibenden Beobachter ist nützlicher als eine Funktionsliste.
Vier Mechanismen, vier Beobachter
Beginnen Sie mit den vier Beziehungen und der Partei, die jede davon draußen halten soll. Die Tabelle unten ist die, die ich in Reviews verwende, weil sie das Gespräch zwingt, einen Beobachter zu benennen statt eine Technologie.
| Mechanismus | Beziehung, die er schützt | Beobachter, den er nicht entfernt |
|---|---|---|
| HTTPS | Die TLS-Verbindung der Anwendung zu ihrem benannten Endpunkt | Das Zugangsnetz sieht weiterhin die Zieladresse |
| DoH | Der DNS-Austausch mit dem gewählten HTTPS-Resolver | Dieser Resolver sieht jede Abfrage |
| ECH | Die sensiblen ClientHello-Felder, wo unterstützt und akzeptiert | Zieladressen und DNS, wenn es nicht abgedeckt ist |
| VPN | Abgedeckte Pakete, die zum VPN-Peer getragen werden | Der VPN-Betreiber sieht die Ziele |
Der Wert der Tabelle liegt in dem, was sie nicht sagt. Sie ordnet die Mechanismen nicht, und sie behauptet nicht, dass die Nutzung aller vier alle vier Beobachter entfernt. Eine Cloud-Webanwendung, die TLS bereits an ihrer eigenen Kante beendet, ist für diesen Austausch vor dem Zugangsnetz geschützt, und kein Tunnel verbessert diese Eigenschaft. Was ein Tunnel ändern kann, ist, welches Netz die äußeren Pakete sieht und welcher Betreiber jetzt auf dem Pfad ist.
Was HTTPS tatsächlich verbirgt
HTTPS schützt den Anwendungsaustausch zwischen dem Client und dem Endpunkt, den das Zertifikat benennt. Es verbirgt nicht die Zieladresse, es verbirgt nicht, dass eine Verbindung stattfand, und es verbirgt nicht den Namen, sofern ECH nicht im Spiel ist. Die Zertifikatsprüfung ist Teil des Schutzes, keine Formalität darum herum.
Ein VPN muss dieses TLS nicht beenden, und ein weiterleitender Ausgang sollte nicht als der authentifizierte Endpunkt der Anwendung behandelt werden. Wenn ein Entwurf den Ausgang entschlüsseln lässt, ist das eine andere Architektur mit einer anderen Vertrauensaussage.
Was DoH und ECH verschieben und was sie hinterlassen
DoH verschiebt den DNS-Austausch zu einem HTTPS-Resolver, was bedeutet, dass dieser Resolver Ihre Abfragen sieht statt des Resolvers des lokalen Netzes. Das ist eine reale und begrenzte Änderung: Der gewählte Resolver wird zu einer Partei, die Abfragen mit den Adressen korrelieren kann, zu denen Sie sich danach verbinden, und genau das ist die Korrelation, die RFC 8484 erörtert. Verschlüsselter Transport macht den Empfänger nicht unwissend über die Abfragen, die er beantwortet.
ECH schützt den sensiblen Teil des ClientHello, sodass ein passiver Beobachter auf dem Pfad den beabsichtigten Servernamen nicht lesen kann. Es hängt von einer unterstützenden Bereitstellung und von der Annahme durch Server und Netz ab, und es lässt andere Kanäle bestehen: Zieladressen bleiben sichtbar, und DNS kann den Namen weiterhin verraten.
Das andere, was ECH nicht tut, ist, sich selbst zu beweisen. Eine Verbindung mit TLS 1.3 ist kein Beleg dafür, dass ECH akzeptiert wurde, und ein Browser, der ECH einem Server ohne Unterstützung anbietet, fällt still zurück. Prüfen Sie den tatsächlichen Zustand der Verbindung, statt ihn aus der Protokollversion abzuleiten.
Das ist die allgemeine Form dieses ganzen Vergleichs: Jeder Mechanismus wird auf seiner eigenen Ebene verifiziert, und keiner von ihnen wird durch den Erfolg eines anderen verifiziert.
Was ein VPN verschiebt und was es hinzufügt
Wenn Webverkehr in ein VPN eintritt, sieht das Zugangsnetz den äußeren Austausch mit dem VPN-Peer statt der einzelnen Anwendungsverbindungen, und der VPN-Betreiber nimmt eine Position auf dem weiteren Pfad ein. Das ist eine Verschiebung der Vertrauensgrenze, nicht ihre Entfernung. Der Betreiber sieht nun, welche Ziele Sie erreichen, selbst wenn der Inhalt durchgehend verschlüsselt bleibt. Ob das eine Verbesserung ist, hängt ganz davon ab, welcher der beiden Parteien Sie weniger vertrauen.
Behalten Sie das HTTPS der Anwendung und den vorgesehenen Resolverschutz bei, während Sie das tun. Ein Tunnel ersetzt keine Zertifikatsprüfung, und die Schutzmaßnahmen eines Resolvers abzuschalten, weil der Verkehr getunnelt wird, entfernt eine Kontrolle, ohne sie zu ersetzen.
Aus der Anforderung auswählen
Nennen Sie die tatsächliche Anforderung, denn sie entscheidet über den Entwurf. Zugang zu privaten Ressourcen, ein verwalteter Ausgangspunkt, eine bestimmte Bedrohung aus dem Zugangsnetz und Geräteautorisierung sind vier verschiedene Bedürfnisse mit vier verschiedenen Antworten, und ein Unternehmen, das nur öffentliche Cloud-Anwendungen nutzt, muss trotzdem Autorisierung und Datenhandhabung entscheiden. Zusätzliche Schichten können angemessen sein, ohne austauschbar zu sein. Eine kompliziertere Verbindung ist keine Anonymitätsmessung, und sie ist für sich genommen kein Sicherheitsargument.
Die ECH-Spezifikation, RFC 9849, lohnt sich zu lesen, weil sie zeigt, was der Mechanismus abdeckt und was nicht, und sie ist ehrlich über die Kanäle, die sie unberührt lässt. Vergleichen Sie die Mechanismen nach dem Beobachter, den jeder entfernt, schreiben Sie diesen Beobachter auf, und entscheiden Sie dann, ob die zusätzliche Schicht ihn adressiert. Wenn die Antwort ist, dass der Beobachter bereits außerhalb Ihres Bedrohungsmodells lag, ist der Tunnel Kosten ohne Nutzen.