TLS läuft im Steuerkanal, nicht durch den ganzen Tunnel

Das Wort TLS in einer VPN-Beschreibung zu finden und daraus zu schließen, dass ein Web-Proxy den Verkehr verstehen wird, ist eine gängige Abkürzung. Innerhalb dieses Protokolls tauschen die Peers ihre eigenen Pakete aus, und TLS läuft als Teil eines Kanals innerhalb dieses Austauschs. Die Nutzlast, um die es dem Benutzer geht, reist in einem anderen Nachrichtenformat, weshalb die beiden nie mit einer gewöhnlichen HTTPS-Sitzung übereinstimmen.

Der Umschlag kommt zuerst

Jedes Tunnelpaket beginnt mit dem eigenen Header des Protokolls: einem Nachrichtentyp, einer Schlüsselkennung und, über einem Bytestrom-Transport, einem Längenpräfix, das markiert, wo das Paket endet. Ein Leser, der diesen Umschlag nicht parst, kann nicht wissen, wo das nächste Feld beginnt.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Diese Skizze ist eine Karte und keine Bytetabelle, weil die genauen Felder vom Nachrichtentyp abhängen, obwohl das erste Oktett immer den Opcode und die Schlüsselkennung zusammenpackt. Den Nachrichtentyp aus der Portnummer zu raten, führt dazu, dass Decoder das Gesehene falsch benennen. Die Reihenfolge ist für die Diagnose entscheidend: Transport, dann der Protokollumschlag, dann eine von zwei Arten von Arbeit. Lesen Sie den Umschlag, bevor Sie sich eine Meinung über das Folgende bilden. Ein Decoder, der an der falschen Stelle beginnt, produziert selbstsicheren Unsinn.

Die Zuverlässigkeitsschicht gehört zum Protokoll

Steuernachrichten brauchen geordnete, bestätigte Zustellung, und das Protokoll sorgt selbst dafür mit Bestätigungen und Neuübertragungen. Eine Bestätigung kann als eigene Nachricht ankommen oder mit einer anderen Steuernachricht reisen, was Spuren für jeden unregelmäßig aussehen lässt, der einen sauberen Austausch erwartet.

Der Vorteil ist, dass der TLS-Handshake einen zuverlässigen Träger bekommt, auch wenn der äußere Transport UDP ist. Der Preis ist, dass ein einzelnes Datagramm nur einen Teil dieses Gesprächs enthalten kann, sodass die Behandlung als eigenständiger TLS-Datensatz Unsinn erzeugt. Die Neuzusammensetzung muss auf der Protokollebene erfolgen. Deshalb sieht ein aufgezeichnetes Paket selten wie ein vollständiger Handshake-Schritt aus.

Den äußeren Transport auf TCP umzustellen, entfernt diese Schicht nicht. Zuverlässiger Transport bedeutet weniger Neuübertragungen auf Protokollebene, nicht dass die Rahmung verschwindet oder der Verkehr zu HTTP wird.

Datenpakete verwenden ein anderes Format

Sobald die Sitzung besteht, kommt die Nutzlast als Datennachrichten an, die innere IP-Pakete oder Ethernet-Frames tragen. Sie sind mit eigenen Schlüsseln und eigener Verarbeitung geschützt und sind keine TLS-Anwendungsdatensätze in irgendeinem Sinn, den eine TLS-Bibliothek akzeptieren würde.

Diese Trennung ist in der Konfiguration sichtbar: Der Steuerkanal und der Datenkanal haben getrennte Verschlüsselungseinstellungen, sodass eine Protokollzeile, die einen nennt, nichts über den anderen sagt. Eine starke Steuerverschlüsselung als Beweis für eine starke Datenverschlüsselung zu lesen, ist ein häufiger Berichtsfehler.

Halten Sie auch ein verwandtes Missverständnis aus der Erklärung heraus. TLS ist kein Public-Key-Kanal neben einem symmetrischen Datenkanal, denn TLS schützt seine Datensätze selbst symmetrisch, sobald Schlüssel etabliert sind. Der wirkliche Unterschied ist Rolle und Paketformat, nicht welche Art von Kryptografie jede Seite verwendet.

Warum ein HTTPS-Proxy nicht helfen kann

Ein Proxy, der TLS terminiert, erwartet einen TLS-Datensatzstrom und darin ein Anwendungsprotokoll. Der Steuerkanal dieses Protokolls wird innerhalb seiner eigenen Rahmung mit einer Zuverlässigkeitsschicht darum herum übertragen, sodass ein terminierender Proxy diese Rahmung als beschädigte Eingabe liest.

Ein transparenter Weiterleiter, der Bytes oder Datagramme ohne Interpretation durchreicht, kann funktionieren, sofern er den Strom nicht umschreibt oder neu zusammensetzt. Die Frage, die man bei jedem Vermittler stellen sollte, ist, ob er den tatsächlichen Transport und die Rahmung weiterleitet, nicht ob er irgendwo TLS unterstützt. Fragen Sie das, bevor Sie einen Abend mit Proxy-Regeln verbringen. Die meisten Fehler hier sind architektonisch und keine fehlende Einstellung.

Eine Spur richtig lesen

Erwarten Sie zuerst einen Steueraustausch, dann eine viel größere Zahl von Datennachrichten, beide über einen Transport. Wenn die Steuerphase abgeschlossen ist und die Datenphase stockt, betrifft der Fehler Schlüssel, Routing oder Filterung des Datenpfads und nicht den Handshake. Zeichnen Sie einige Datennachrichten auf und prüfen Sie, ob sie den Client überhaupt verlassen. Diese eine Beobachtung halbiert die Suche.

Historische Schlüsselmethode-Beschreibungen in der Protokolldokumentation bedeuten nicht, dass eine bestimmte Version noch jedes alte Format unterstützt. Prüfen Sie die Version, die Sie ausführen, bevor Sie eine Erwartung auf einen Absatz bauen, der beschreibt, wie die Dinge früher funktionierten.