Es gibt Firewalls, die den Datenverkehr analysieren und ihn blockieren, wenn er nicht erwünscht ist. Wie gut funktionieren diese Firewalls bei verschlüsseltem Datenverkehr, z. B. HTTPS oder IMAP über SSL?
Ein Beispiel: Kann eine Firewall zwischen HTTPS-Verkehr auf Port 443 und beispielsweise gesichertem Remote-Desktop-Verkehr über 443 unterscheiden?
Antwort1
In Ihrem speziellen Beispiel ist es möglich.
HTTPS startet eine TLS-Sitzung mit der Remote-Verbindung.
TLSv1 Client Hello
Secure RDP startet eine RDP-Sitzung, die eine TLS-gesicherte Verbindung zwischen den beiden Enden der Sitzung aushandelt.
X.224 Connection Request (0xe0)
Da die Protokolle zum Starten der Sitzung unterschiedlich sind, sollte eine Stateful Firewall in der Lage sein, zwischen dem Starten einer HTTPS-Verbindung und etwas anderem zu unterscheiden.
Im allgemeinen Fall kann eine Firewall etwas wie SSH-über-HTTPS nicht erkennen, da der SSH-Verkehr im HTTPS-Verkehr verborgen ist. Die einzige Möglichkeit, dies zu erkennen, ist eine heuristische Analyse der Verkehrsmuster, aber ich kenne kein Programm, das das tut.
Für IMAP gibt es zwei Arten der Sicherung. Eine davon ist SSL, die andere TLS. Die SSL-Methode sieht genauso aus wie eine HTTPS-Verbindung, nur über einen anderen Port, und wenn der Remote-Port derselbe ist, kann man nicht viel dagegen tun. TLS hingegen wird zwischen beiden Enden der Konversation ausgehandelt, sodass der Sitzungsstart deutlich unterschiedlich ist und leicht erkannt werden kann.
Wichtig ist, dass SSL einen TCP-Wrapper erstellt, durch den der Datenverkehr geleitet wird. Viele Protokolle enthalten eine Methode ausgehandelter Sicherheit innerhalb des Protokolls selbst, die weitgehend dieselben Technologien nutzt wie der Wrapper, aber eine andere Methode zum Starten der Sitzung verwendet, wodurch sie unterscheidbar ist.
Antwort2
Einige Firewall-/Proxy-Produkte können einen „autorisierten Man-in-the-Middle-Angriff“ auf TLS-Verbindungen durchführen; Squid nennt diese Funktion beispielsweise „SSL-Erhöhung”. Ein Proxy-Server, der dies tut, hat vollen Zugriff auf die Klartextdaten, die innerhalb der TLS-Sitzung übertragen werden. Ein Client hinter einem solchen Proxy erhält jedoch ein anderes Serverzertifikat (das vom Proxy selbst und nicht vom echten Server bereitgestellt wird), was zu TLS-Fehlern oder -Warnungen führt, es sei denn, der Client ist so konfiguriert, dass er solche Zertifikate erwartet (indem das Proxy-CA-Zertifikat zur Liste der vertrauenswürdigen Stammzertifikate hinzugefügt wird).