7
Wie funktioniert ein HTTPS Proxy? Ist das zeitgemäß?
Hallo,
ich war bisher immer der Meinung wenn im Browser ein Proxyserver für HTTPS eingetragen ist, dann stellt der Proxyserver lediglich einen TCP-Tunnel bereit, über den dann die eigentliche HTTPS-Verbindung zw. Browser und dem Ziel-Webserver läuft. Ohne weitere Schweinereien ist die Verbindung dann trotzdem gesichert und die Daten liegen dann zu keinem Zeitpunkt zwischen Client und Webserver unverschlüsselt vor.
Was damit natürlich auch gemeint sein kann ist evtl. eine HTTPS-Verbindung zw. Client und Proxy... das wäre ja dann lediglich eine https-Adresse als Proxy-Adresse sowie ein gültiges Zeritifkat (hab ich aber selber noch nicht ausprobiert).
Jetzt habe ich gelesen, dass auf "ALGs" (Contentfilter o.ä.) die Verbindung z.T. 'aufgebrochen' wird. Bekommt man sowas am Client mit? Erledigt sich sowas nicht in kürze wieder aufgrund von HPKP (Public Key Pinning)?
Danke.
Gruß
Dieter
ich war bisher immer der Meinung wenn im Browser ein Proxyserver für HTTPS eingetragen ist, dann stellt der Proxyserver lediglich einen TCP-Tunnel bereit, über den dann die eigentliche HTTPS-Verbindung zw. Browser und dem Ziel-Webserver läuft. Ohne weitere Schweinereien ist die Verbindung dann trotzdem gesichert und die Daten liegen dann zu keinem Zeitpunkt zwischen Client und Webserver unverschlüsselt vor.
Was damit natürlich auch gemeint sein kann ist evtl. eine HTTPS-Verbindung zw. Client und Proxy... das wäre ja dann lediglich eine https-Adresse als Proxy-Adresse sowie ein gültiges Zeritifkat (hab ich aber selber noch nicht ausprobiert).
Jetzt habe ich gelesen, dass auf "ALGs" (Contentfilter o.ä.) die Verbindung z.T. 'aufgebrochen' wird. Bekommt man sowas am Client mit? Erledigt sich sowas nicht in kürze wieder aufgrund von HPKP (Public Key Pinning)?
Danke.
Gruß
Dieter
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 341007
Url: https://administrator.de/contentid/341007
Ausgedruckt am: 22.11.2024 um 06:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
Klassische Proxies haben bei ssl-Verbindungen einfach nur die Daten weitergereicht, ohne diese zu manipulieren. Das bedeutet aber auch, daß eon Contentfilter auf dem Proxy nicht greift, was in vielen Firmenumgebungen nivht erwünscht ist. Deswegen eerden in solchen Umgebungen die ssl-Verbindungen aufgebrochen und durch eine neue ssl-verbindung des proxies zum Server ersetzt.
Der client merkt das anhand der Zertifikats, das er präsentiert bekommt (Du prüfst doch hoffentlich immer die Zertifikate, auch wenn Dein Browser sich nicht beschwert?)
Allerdings haben da einige Hersteller bei ihren ALG so geschlampt, daß die Sicherheit der Verbndung durvh das ALG eher gefährdet war.
Das Key-Pinnng wird nur die nächste Stufe der Eskalation einleiten, weil Firmen ihre Verbindungen nach draußen kntrollieren wollen.
lks
Klassische Proxies haben bei ssl-Verbindungen einfach nur die Daten weitergereicht, ohne diese zu manipulieren. Das bedeutet aber auch, daß eon Contentfilter auf dem Proxy nicht greift, was in vielen Firmenumgebungen nivht erwünscht ist. Deswegen eerden in solchen Umgebungen die ssl-Verbindungen aufgebrochen und durch eine neue ssl-verbindung des proxies zum Server ersetzt.
Der client merkt das anhand der Zertifikats, das er präsentiert bekommt (Du prüfst doch hoffentlich immer die Zertifikate, auch wenn Dein Browser sich nicht beschwert?)
Allerdings haben da einige Hersteller bei ihren ALG so geschlampt, daß die Sicherheit der Verbndung durvh das ALG eher gefährdet war.
Das Key-Pinnng wird nur die nächste Stufe der Eskalation einleiten, weil Firmen ihre Verbindungen nach draußen kntrollieren wollen.
lks
Was ich dann aber nicht ganz verstehe:
Ich baue eine Verbindung zu z.B. https://www.google.com auf... das Zertifikat was mir der ALG präsentiert ist aber doch keinesfalls auf google.com ausgestellt - warum schlägt der Browser nicht Alarm, dass das Zertifikat nicht passt?
Ich baue eine Verbindung zu z.B. https://www.google.com auf... das Zertifikat was mir der ALG präsentiert ist aber doch keinesfalls auf google.com ausgestellt - warum schlägt der Browser nicht Alarm, dass das Zertifikat nicht passt?
Das Zertifikat muss vorher auf dem Client in die Vertrauenswürdigen Stammzertifizierungsstellen importiert werden z.B. für den IE und Chrome per GPO oder den Firefox per Script.
Ansonsten wäre ja das ganze HTTPS ad absurdum geführt.
Am Client erkennst du das, indem du das Zertifikat inspizierst; dann ist beispielsweise das google.de SSL-Zertifikat signiert von deiner Firma und nicht Google.
Gruß
Ansonsten wäre ja das ganze HTTPS ad absurdum geführt.
Am Client erkennst du das, indem du das Zertifikat inspizierst; dann ist beispielsweise das google.de SSL-Zertifikat signiert von deiner Firma und nicht Google.
Gruß
Zitat von @flyingKangaroo:
Was ich dann aber nicht ganz verstehe:
Ich baue eine Verbindung zu z.B. https://www.google.com auf... das Zertifikat was mir der ALG präsentiert ist aber doch keinesfalls auf google.com ausgestellt - warum schlägt der Browser nicht Alarm, dass das Zertifikat nicht passt?
Was ich dann aber nicht ganz verstehe:
Ich baue eine Verbindung zu z.B. https://www.google.com auf... das Zertifikat was mir der ALG präsentiert ist aber doch keinesfalls auf google.com ausgestellt - warum schlägt der Browser nicht Alarm, dass das Zertifikat nicht passt?
Weil die das root-Zertfikat daß das ALG-zertifikat ausgestellt hat, im Browser als Vertrauenswürdig eingetragen wurde oder das ALG stellt on-the-fly Zertifikate aus und signert sie mt einem Vertrauenswürdigen Zertifikat so das der brwoser denkt er kommuniziert wirklich mit google. Symantec ist dahingehend schon negativ aufgefallen, ist aber nicht der einzige böse Bube in diesem Spiel.
Man muß sich bewußt machen, das die ALGs genau das machen, was man als (erfolgreichen) MITM-Angriff bezeichnet.
Deswegen geht google inzwischen zu Zertificate-pinning bei ihren domains und produkten über, damit die user das merken.
lks
Danke. Jetzt hab ich's verstanden 
Zitat von @flyingKangaroo:
Erledigt sich sowas nicht in kürze wieder aufgrund von HPKP (Public Key Pinning)?
Erledigt sich sowas nicht in kürze wieder aufgrund von HPKP (Public Key Pinning)?
Chrome wird Key Pinning vermutlich wieder aufgeben, da es zu mehr Problemen geführt hat als es gelöst hat (https://www.golem.de/news/https-chrome-will-http-public-key-pinning-wied ..)
LG Dani
Aber andere Wege sind eigentlich nicht vorstellbar, oder?
Will sagen: an der Zertifikatskette müsste man es eigentlich IMMER merken, wenn HTTPS aufgebrochen wurde, oder?
Das Datenblatt von z.B. "McAfee Web Gateway" ließt sich m.E. nämlich ziemlich gruselig - fast so als hätten Sie die perfekte Lösung gefunden, SSL vollends auszuhebeln.
In so einem Netzwerk würde ich z.B. ungern auf irgendwelche vertraulichen persönlichen Daten (Banking, Webmail) zugreifen...
Will sagen: an der Zertifikatskette müsste man es eigentlich IMMER merken, wenn HTTPS aufgebrochen wurde, oder?
Das Datenblatt von z.B. "McAfee Web Gateway" ließt sich m.E. nämlich ziemlich gruselig - fast so als hätten Sie die perfekte Lösung gefunden, SSL vollends auszuhebeln.
In so einem Netzwerk würde ich z.B. ungern auf irgendwelche vertraulichen persönlichen Daten (Banking, Webmail) zugreifen...
