Proxy Authentifizierung Sicherheit der Anmeldedaten

[ronker]

Bei uns in der Firma gibt es für den Internetzugang einen Proxy Server. In den Windows Einstellungen ist dafür die Adresse für den Proxy http://xyz.xyz und ein entsprechender Port eingetragen. Das ist durch eine Richtlinie auch nicht änderbar.

Ist die Authentifizierung ggü. dem Proxy in dem Fall unsicher? Könnte (theoretisch) jemand im internen Netzwerk die Anmeldedaten mitlesen? Die HTML Webseite zum ändern des Passworts ist hingegen mit SSL abgesichert (https).

Oftmals gibt man ja auch als Adresse eine IP Adresse an ohne http(s) wie wäre das in diesem Fall?

 

[Zuse1]

Alles was über irgendeinen Proxy läuft ist theoretisch einsehbar. Nutzt du SSL, hast Du natürlich einen gewissen Schutz was den Inhalt betrifft. Aber auch SSL-Verbindungen sind heutzutage knackbar.

Willst Du eine Seite direkt über die IP-Adresse aufrufen, besteht meistens keine SSL-Verschlüsselung.

Ergänzung (20. Januar 2020)

Alles was über irgendeinen Proxy läuft ist theoretisch einsehbar. Nutzt du SSL, hast Du natürlich einen gewissen Schutz was den Inhalt betrifft. Aber auch SSL-Verbindungen sind heutzutage knackbar.

Willst Du eine Seite direkt über die IP-Adresse aufrufen, besteht meistens keine SSL-Verschlüsselung.

Solltest Du Dich generell für sichere Internetverbingen interessen, wäre dieser Artikel vielleicht auch noch was für Dich:
https://www.heise.de/security/meldu...-Hersteller-Finger-weg-von-HTTPS-3620159.html

 

[RalphS]

Gab mal vor Urzeiten HTTPS Proxies.

Haben aber keinen Mehrwert, da die HTTPS Proxies noch ein weiteres Zertifikat für ihre eigene Verbindung erforderten und man irgendwann auf die Idee kam, daß die ursprüngliche Verbindung sicher genug sei.

HTTPS ist streng genommen ein Tunnel, daran ändert auch der Proxy nichts. Man bekommt halt eine HTTP Verbindung zum Proxy (sagen wir per 3128/tcp) wo auch die Metadaten im Plaintext sichtbar sind.
Aber die Antwort ist einee gemäß ursprünglicher Anforderung verschlüsselte Nutzlast.

Proxies sind damit immer inhärerent ein bißchen "leaky" und der Betreiber kriegt eh die meisten Informationen (außer für HTTPS die konkreten Inhalte) deswegen ist Firma okay, "da draußen" aber normalerweise nicht.

@Zuse1 danke für den Link, guck ich mir gleich mal an, wie die das begründen wollen. Vorab: SSL macht die Daten durch den Tunnel nicht inhärent sicher, sodaß der Scanner die durchaus prüfen muß, egal in welcher Form die auf den PC kommen: per Stick, per DVD, per FTP oder eben per HTTPS.

Egal wie man sich das dreht, der AV Scanner muß die anfallenden Daten lesen, völlig egal, wo da angesetzt wird, und sei es erst hinter dem SSL-Tunnel.

-- Nachtrag: Okay, den Teil stellen die Kollegen auch gar nicht in Frage, gut.
-- Daß man, wenn man aktiver Teil der SSL-Verbindung wird, natürlich auch eine gewisse Verantwortung hat und nicht einfach irgendwelchen bekannt kaputten Käse implementieren darf... steht wieder auf einem anderen Blatt.
-- Daher, ja natürlich muß die Verbindung geprüft werden, aber um das zu bewerkstelligen dürfen dann natürlich nicht "jahrzehntealte" Templates mit einfachem DES oder sowas verwendet werden.
-- "Möglicherweise" kann man da ja was erfinden, daß die AV-Zertifikate erst generiert und dann mit Installation vom AV-Hersteller signiert werden müssen. Oder besser noch, irgendwem anders. Gibt sicher Wege.
-- SSL Scanning verteufeln ist aber definitiv der falsche Weg.

 

[ronker]

Gab mal vor Urzeiten HTTPS Proxies.

Haben aber keinen Mehrwert, da die HTTPS Proxies noch ein weiteres Zertifikat für ihre eigene Verbindung erforderten und man irgendwann auf die Idee kam, daß die ursprüngliche Verbindung sicher genug sei.

HTTPS ist streng genommen ein Tunnel, daran ändert auch der Proxy nichts. Man bekommt halt eine HTTP Verbindung zum Proxy (sagen wir per 3128/tcp) wo auch die Metadaten im Plaintext sichtbar sind.
Aber die Antwort ist einee gemäß ursprünglicher Anforderung verschlüsselte Nutzlast.

Proxies sind damit immer inhärerent ein bißchen "leaky" und der Betreiber kriegt eh die meisten Informationen (außer für HTTPS die konkreten Inhalte) deswegen ist Firma okay, "da draußen" aber normalerweise nicht.

Vielen Dank für die Antworten!

Nur um nochmal zu verdeutlichen worum es mir mit der Frage eigentlich ging: Wenn ich mich im Firmennetzwerk über http://xyz.xyz ggü. dem Proxy mit Benutzername/Kennwort authentifiziere bevor ich diesen nutze, wird in dem Fall doch das Passwort von meinem Browser zum Proxy hin über das Firmennetzwerk im Klartext übertragen und könnte ggf. mitgelesen werden bzw. könnte sich jemand anderes im Firmennetzwerk ggü. dem Proxy auch als mich ausgeben indem er z.B. einen Token o.ä. mitschneidet?

Wenn ja müsste doch eigentich besser eine Authentifizierung bzw. Kommunikation zum Proxy hin auch über https://xyz.xyz erfolgen?

 

[BlubbsDE]

Wenn ein Proxy zwischen Dir und dem Netz ist, dann läuft alles über ihn. Alles.

 

[RalphS]

Aber nicht das pw im Klartext. Das wäre auch da gröbst fahrlässig.

Normal geht das in Richtung Negotiate. Da wird das bestmögliche rausgesucht. Das kann auch Kerberos sein, irgendein CHAP Modell oder sonst was.

 

[Zuse1]

xyz.xyz unterstüzt grundsätzlich ja HTTPS, nur wird dies in dem Fall von ronker nicht explizit angefordert, sprich im System ist HTTP://xyz.xyz fest konfiguriert. Die meisten Seiten versuchen ja automatisch von HTTP auf HTTPS umzuleiten, zumindest wenn Webseiten im Webbrowser aufgerufen werden. Ist jetzt nur die Frage ob es sich auch so verhält wenn man dies fest im System verankert, oder ob bei einer expliziten HTTP Angabe auch nur HTTP genutzt wird?

 

[RalphS]

(Web-)Proxy ist nicht Webserver. Sie verwenden dasselbe Protokoll - bzw eigentlich eher eine Ableitung davon -- aber mehr nicht.

"Unterstützt HTTPS" ist ein bißchen weit hergeholt. Ja, es geht damit, aber "unterstützt" beschränkt sich nur darauf, daß der Proxy kapiert, was man von ihm will. Schließlich muß er die Anfrage vom Client in eine eigene Abfrage umbauen und muß wissen und in der Lage sein, selber HTTPS-Verbindungen aufzubauen. Das ist aber alles.

Die Metainfo vom und zum Proxy sind unverschlüsselt. Nur die Antwort, die der Proxy liefert (sprich das, was der Client über ihn angefordert hatte) ist verschlüsselt, und selbst das ist getunnelt.

Rein technisch, wo SSL die Verbindung verschlüsselt und die Rohdaten tunnelt, ist es bei HTTPS-über-Proxy genau andersherum. Die Verbindung ist unverschlüsselt (via HTTP) aber die Antwort vom Webserver, die der Proxy ja an den Client zurückgeben muß, die hängt sozusagen als (verschlüsseltes) Attachment hinten dran.

Der Client kann ja gar nicht mit dem Webserver reden. Könnte er das, bräuchten wir keinen Proxy. Es gibt also immer mindestens vier einzelne Verbindungsteile Client-Proxy-Webserver "hin" und Webserver-Proxy-Client zurück und das Stück zwischen Client und Proxy läuft immer über HTTP-ohne-S, egal was der Client angefordert hatte.

Und eben WEIL die Verbindung Client-zu-Proxy unverschlüsselt ist, müssen so Dinge wie Proxy-Credentials selbst verschlüsselt sein. Paßwort im Plaintext über HTTPS ist überhaupt kein Problem, wenn man HTTPS genug vertraut. Da das aber nicht der Fall ist, werden andere Mechanismen eingesetzt, "üblicherweise" über einen dritten Pfad. Sprich bei Kerberos, der Client zeigt sein Ticket vor und der Proxy validiert es gegen den Domaincontroller, und nur wenn der sagt "Ja, das Client-Ticket was du mir da vorgelegt hast ist okay" läßt er die Verbindung zu. Ziel ist, Paßwörter eben nicht über die letztlich unsichere HTTP-Verbindung zwischen Client und Proxy zu schicken, auch dann, wenn das Firmennetz eigentlich vertrauenswürdig eingestuft werden kann (mitschnuppern kann ja immer irgendwer).

Wirklich interessant wird es erst, wenn das Ganze über irgendwelche unbekannten Proxies da draußen im WWW getunnelt wird. Aber da kann man sich ja den Wolf reden, die sind ja genauso beliebt wie VPN-Services, auch wenn sie aus exakt denselben Gründen nicht genutzt werden sollten.