SSTP und SSL 3.0: das Etikett gegen die ausgehandelte Version

Zwei Personen können dieselbe SSTP-Bereitstellung ansehen und zu gegensätzlichen Schlüssen kommen. Die eine liest die Produktdokumentation, sieht die Buchstaben SSL und nimmt an, der Tunnel laufe ein vor Jahren eingestelltes Protokoll. Die andere zeigt auf einen modernen Handshake und erklärt die Frage für erledigt. Beide argumentieren von Etiketten statt von der ausgehandelten Version, und nur eines von beidem ist ein Beweis. Der Vergleich, der sich lohnt, ist der zwischen dem, was der Name verspricht, und dem, was der Dienst tatsächlich auswählt.

Zwei Antworten auf dieselbe Frage

Das Etikett-Argument ist schnell formuliert: SSTP wird als sicheres Tunnelling-Protokoll über Sockets beschrieben, der historische Name nennt SSL, also muss die Verbindung SSL 3.0 sein. Es hält sich, weil der Name tatsächlich aus dieser Linie stammt und weil die meisten, die es wiederholen, noch nie einen Handshake angesehen haben. Es hält sich auch, weil die Schlussfolgerung konservativ klingt, als wäre das Schlimmste anzunehmen die sichere Wahl. Das Schlimmste anzunehmen und die tatsächliche Version zu messen sind verschiedene Tätigkeiten, und nur eine von beiden ändert etwas.

Das Beweis-Argument stellt eine engere Frage. Auf welche Protokollversion haben sich dieser Client und dieser Server an diesem Endpunkt zu dieser Zeit geeinigt? Die Antwort kommt von dem Dienst, der TLS terminiert, nicht von einer Marketingseite oder einem Browser, der eine ähnlich benannte Website erreicht hat.

Die beiden Argumente unterscheiden sich darin, was sie belegen können. Das Etikett kann eine alte Bereitstellung nicht von einer gepatchten unterscheiden, und der Handshake kann nicht sagen, was ein unabhängiger Dienst auf demselben Host tut. Nutzen Sie das zweite und hören Sie auf, das erste zu nutzen.

Lesen Sie die Version, die der Dienst tatsächlich auswählt

Beginnen Sie mit der Benennung der Komponenten: die Client-Implementierung, die Server-Implementierung, der TLS-Endpunkt und alles dazwischen, das TLS beendet und neu aufbaut. Ein Load Balancer, der TLS beendet und mit dem Backend einfaches HTTP spricht, ändert, welche Richtlinie des Geräts Sie lesen müssen.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Notieren Sie Endpunkt und Zeitpunkt zusammen mit dem Ergebnis, denn eine spätere Richtlinienänderung macht eine undatierte Beobachtung wertlos. Wiederholen Sie die Prüfung von einem Client auf demselben Netzwerkpfad wie die Nutzer, die Sie betreuen, denn ein Abfanggerät kann TLS mit eigenen Einstellungen terminieren. Wenn die beiden Positionen nicht übereinstimmen, haben Sie die Komponente gefunden, auf die es ankommt. Wenn sie übereinstimmen, haben Sie einen Beweis statt eines Slogans.

Trennen Sie das Datensatzfeld von der Aushandlung

Eine altertümlich wirkende Versionsnummer in einem Feld ist nicht dieselbe Tatsache wie eine SSL 3.0-Sitzung. RFC 7568 behandelt die Version der Aufzeichnungsschicht und das ausgehandelte Protokoll als getrennte Belange, und genau aus dieser Unterscheidung stammen selbstsichere falsche Antworten. Lesen Sie das ausgehandelte Protokoll, dann die Chiffre, und ziehen Sie erst dann eine Schlussfolgerung über die Sitzung.

Dasselbe Dokument ist beim Protokoll selbst eindeutig: SSL 3.0 darf nicht verwendet werden, und die Aushandlung oder das Zurückfallen darauf ist untersagt. Die Begründung ist die defekte CBC-Konstruktion, die der POODLE-Angriff ausnutzte, und das ist eine Eigenschaft des Protokolls, nicht der Konfiguration einer einzelnen Anwendung.

Deshalb ist „diese Arbeitslast lässt sich wahrscheinlich schwer ausnutzen“ kein Argument dafür, SSL 3.0 aktiviert zu lassen. Die Anforderung lautet, das Protokoll zu entfernen, nicht, eine Debatte über eine einzelne Demonstration zu gewinnen.

SSL 3.0 außer Betrieb nehmen, mit einer Richtlinie, die Sie tragen können

Unter Windows liegen die Schannel-Protokolleinstellungen unter dem Schlüssel Protocols und werden je Client- und je Serverrolle gelesen; deshalb kann eine Änderung, die eine Richtung repariert, die andere unberührt lassen. Die aktuellen Einstellungen und ihre Neustartanforderungen sind von Microsoft dokumentiert, und eine TLS-Bibliothek eines Drittanbieters auf demselben Host ignoriert sie vollständig.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Ändern Sie die Richtlinie über den unterstützten Verwaltungsweg, bestätigen Sie, dass der zuständige Dienst seine Konfiguration neu übernimmt, und behalten Sie einen genehmigten Rückweg. Ein breites Registrierungsskript aus einer anderen Umgebung einzufügen, ist der Weg, auf dem aus der Reparatur eines Dienstes ein Ausfall für jeden TLS-Client auf der Maschine wird. Der Neustartumfang zählt hier: Eine Einstellung, die angewendet aussieht, kann noch im Speicher eines Dienstes gehalten werden, der sie nicht neu geladen hat.

Ein Peer, der noch eine veraltete Version verlangt, braucht ein Update oder einen Migrationsplan. Eine undokumentierte Ausnahme, die das alte Protokoll still wiederherstellt, ist keine Kompatibilitätsstrategie, und sie wird das nächste Audit nicht überstehen.

Nehmen Sie die Änderung mit frischen Verbindungen ab

Testen Sie nach der Richtlinienänderung mit neuen Sitzungen, denn eine vor der Änderung aufgebaute Verbindung beweist nichts über die jetzt geltende Konfiguration. Bestätigen Sie, dass das erlaubte Protokoll erfolgreich ist und das verbotene über den autorisierten Prüfprozess scheitert, und lassen Sie Zertifikatsidentität und Vertrauensprüfungen genau so, wie sie waren.

Denken Sie daran, was der Handshake nicht abdeckt. SSTP trägt nach der TLS-Schicht eine PPP-Authentifizierung, eine moderne Protokollversion sagt also nichts darüber aus, welcher Benutzer autorisiert wurde oder welche Ressourcen die Sitzung erreichen darf. Das sind getrennte Kontrollen mit getrennten Belegen.

Schreiben Sie das Ergebnis als Dienst, Backend, erlaubte Richtlinie und beobachtete Version auf. Dieser Datensatz beantwortet die Sicherheitsfrage präzise, was weder das Etikett-Argument noch ein Argument aus Unbequemlichkeit je schafft.