Diese Website wurde größtenteils automatisch von der englischen Version
übersetzt. Wir entschuldigen uns für eventuelle
Übersetzungsfehler.
x
Proxy Sicherheit & Bedrohungsmodell
Der öffentliche Proxy wurde entwickelt, um die Kommunikation
zwischen einem Client und einem privaten Proxy-Endpunkt zu
vermitteln, ohne die TLS-Verschlüsselung zwischen diesen beiden
aufzubrechen. Er erreicht dies, indem er den TLS-Handshake
instrumentiert, insbesondere durch das Parsen des
ClientHello Pakets, das vom Client gesendet wird, um
die Verbindung zum privaten Proxy zu initiieren. Dieses Paket ist
in RFC-5246 [^1] beschrieben und enthält normalerweise eine
ServerNameList -Erweiterung, wie in RFC-6066 [^2]
beschrieben, die den Servernamen angibt, zu dem der Client eine
Verbindung herstellen möchte. HTTPs-Server verwenden diese
Informationen in der Regel, um das passende Zertifikat auszuwählen,
da ein einziger Server oft Inhalte für viele Domänen hostet. Ebenso
kann der öffentliche Proxy diese Informationen verwenden, um
festzustellen, welcher private Proxy (falls vorhanden) die
Verbindung des Clients bearbeiten kann. Er kann dann eine
TCP-Verbindung zu diesem privaten Proxy öffnen und den gesamten
TCP-Stream (einschließlich des Pakets HelloClient ) an
ihn weiterleiten. Auf diese Weise fungiert der öffentliche Proxy
als nicht vertrauenswürdiger Mann in der Mitte zwischen dem Client
und dem privaten Proxy und leitet verschlüsselte Daten zwischen
ihnen weiter.
Bedrohungsmodell
Unser Bedrohungsmodell geht davon aus, dass der öffentliche
Proxy vollständig kompromittiert werden kann. In Szenario 1 erlangt
ein Angreifer die vollständige Kontrolle über den öffentlichen
Proxy-Server und ist in der Lage, den Servercode durch seinen
eigenen Code zu ersetzen, der z.B. darauf abzielt, die zwischen dem
Client und dem privaten Proxy ausgetauschten Daten zu exfiltrieren.
In Szenario 2 gelingt es einem Angreifer, den für den öffentlichen
Proxy bestimmten Datenverkehr auf seinen eigenen Server umzuleiten,
wo er wie in Szenario 1 beliebigen Code ausführen kann, um z.B.
Daten zu exfiltrieren.
Beide Szenarien stellen einen Man-in-the-Middle-Angriff (MITM)
dar. Systeme, die TLS implementieren, sind so konzipiert, dass sie
solche Angriffe mit Hilfe einer Vertrauenskette, die durch eine
Public-Key-Infrastruktur bereitgestellt wird, abwehren. Unter
idealen Umständen ist es für einen MITM-Angreifer unmöglich, dem
Client ein gültiges TLS-Zertifikat vorzulegen, so dass dieser sich
weigert, eine Verbindung mit dem Server herzustellen. Mit der
Einführung des ACME-Protokolls [^3] ist es für einen Angreifer
jedoch möglich geworden, auf einfache Weise ein gültiges
TLS-Zertifikat für einen Hostnamen zu generieren, dessen
Server-Endpunkt er kontrolliert. In beiden oben genannten Szenarien
würde dies den Angreifer in die Lage versetzen, einen ACME-Anbieter
wie LetsEncrypt zu verwenden, um ein gültiges TLS-Zertifikat zu
generieren und dann die Client-Server-TLS-Verbindung ohne Wissen
des Clients oder des Servers zu beenden und zu vermitteln.
Um dieses Risiko zu minimieren, sollte die Ausstellung von
Zertifikaten über ACME für alle Hostnamen, die über den
öffentlichen Proxy vermittelt werden, eingeschränkt werden. Darüber
hinaus sollten
Mechanismen zur Transparenz von Zertifikaten (CT) eingesetzt
werden, die es dem Client ermöglichen, die Falschausstellung eines
Zertifikats durch einen MITM-Angreifer zu erkennen.
Ein unabhängiges Risiko in den Szenarien 1 und 2 ist die
Fähigkeit des Gegners, die Metadaten der verschlüsselten Verbindung
aufzuzeichnen, was ebenfalls sensible Informationen offenbaren
kann. Um dieses Risiko zu verringern, sollten Techniken zur
Verschleierung von Metadaten auf die Client-Server-Kommunikation
angewendet werden.
Schließlich können die Angreifer aus den Szenarien 1 und 2 auch
den Dienst für den Client und den Server verweigern, indem sie die
Kommunikation zwischen ihnen unterbrechen. Dieses Risiko lässt sich
in diesen Szenarien aufgrund der privilegierten Position der
Angreifer nicht ohne weiteres eindämmen. Denial-of-Service
(DoS)-Angriffe durch externe Angreifer können mit gängigen
Techniken abgewehrt werden, die hier nicht näher erläutert
werden.
Proxy Sicherheit & Bedrohungsmodell
Der öffentliche Proxy wurde entwickelt, um die Kommunikation zwischen einem Client und einem privaten Proxy-Endpunkt zu vermitteln, ohne die TLS-Verschlüsselung zwischen diesen beiden aufzubrechen. Er erreicht dies, indem er den TLS-Handshake instrumentiert, insbesondere durch das Parsen des
ClientHelloPakets, das vom Client gesendet wird, um die Verbindung zum privaten Proxy zu initiieren. Dieses Paket ist in RFC-5246 [^1] beschrieben und enthält normalerweise eineServerNameList-Erweiterung, wie in RFC-6066 [^2] beschrieben, die den Servernamen angibt, zu dem der Client eine Verbindung herstellen möchte. HTTPs-Server verwenden diese Informationen in der Regel, um das passende Zertifikat auszuwählen, da ein einziger Server oft Inhalte für viele Domänen hostet. Ebenso kann der öffentliche Proxy diese Informationen verwenden, um festzustellen, welcher private Proxy (falls vorhanden) die Verbindung des Clients bearbeiten kann. Er kann dann eine TCP-Verbindung zu diesem privaten Proxy öffnen und den gesamten TCP-Stream (einschließlich des PaketsHelloClient) an ihn weiterleiten. Auf diese Weise fungiert der öffentliche Proxy als nicht vertrauenswürdiger Mann in der Mitte zwischen dem Client und dem privaten Proxy und leitet verschlüsselte Daten zwischen ihnen weiter.Bedrohungsmodell
Unser Bedrohungsmodell geht davon aus, dass der öffentliche Proxy vollständig kompromittiert werden kann. In Szenario 1 erlangt ein Angreifer die vollständige Kontrolle über den öffentlichen Proxy-Server und ist in der Lage, den Servercode durch seinen eigenen Code zu ersetzen, der z.B. darauf abzielt, die zwischen dem Client und dem privaten Proxy ausgetauschten Daten zu exfiltrieren. In Szenario 2 gelingt es einem Angreifer, den für den öffentlichen Proxy bestimmten Datenverkehr auf seinen eigenen Server umzuleiten, wo er wie in Szenario 1 beliebigen Code ausführen kann, um z.B. Daten zu exfiltrieren.
Beide Szenarien stellen einen Man-in-the-Middle-Angriff (MITM) dar. Systeme, die TLS implementieren, sind so konzipiert, dass sie solche Angriffe mit Hilfe einer Vertrauenskette, die durch eine Public-Key-Infrastruktur bereitgestellt wird, abwehren. Unter idealen Umständen ist es für einen MITM-Angreifer unmöglich, dem Client ein gültiges TLS-Zertifikat vorzulegen, so dass dieser sich weigert, eine Verbindung mit dem Server herzustellen. Mit der Einführung des ACME-Protokolls [^3] ist es für einen Angreifer jedoch möglich geworden, auf einfache Weise ein gültiges TLS-Zertifikat für einen Hostnamen zu generieren, dessen Server-Endpunkt er kontrolliert. In beiden oben genannten Szenarien würde dies den Angreifer in die Lage versetzen, einen ACME-Anbieter wie LetsEncrypt zu verwenden, um ein gültiges TLS-Zertifikat zu generieren und dann die Client-Server-TLS-Verbindung ohne Wissen des Clients oder des Servers zu beenden und zu vermitteln.
Um dieses Risiko zu minimieren, sollte die Ausstellung von Zertifikaten über ACME für alle Hostnamen, die über den öffentlichen Proxy vermittelt werden, eingeschränkt werden. Darüber hinaus sollten Mechanismen zur Transparenz von Zertifikaten (CT) eingesetzt werden, die es dem Client ermöglichen, die Falschausstellung eines Zertifikats durch einen MITM-Angreifer zu erkennen.
Ein unabhängiges Risiko in den Szenarien 1 und 2 ist die Fähigkeit des Gegners, die Metadaten der verschlüsselten Verbindung aufzuzeichnen, was ebenfalls sensible Informationen offenbaren kann. Um dieses Risiko zu verringern, sollten Techniken zur Verschleierung von Metadaten auf die Client-Server-Kommunikation angewendet werden.
Schließlich können die Angreifer aus den Szenarien 1 und 2 auch den Dienst für den Client und den Server verweigern, indem sie die Kommunikation zwischen ihnen unterbrechen. Dieses Risiko lässt sich in diesen Szenarien aufgrund der privilegierten Position der Angreifer nicht ohne weiteres eindämmen. Denial-of-Service (DoS)-Angriffe durch externe Angreifer können mit gängigen Techniken abgewehrt werden, die hier nicht näher erläutert werden.
[^1] : RFC-5264 [^2] : RFC-6066 [^3] : RFC-8555