Hi,
ich will einen http(s) Proxy einrichten, der bestimmte statische Inhalte auch dann cachen kann, wenn die Seite per SSL verfügbar ist.
Vieleicht mit Squid.
Zusätzlich will ich eine aktive Introspektion oder Deep-Packet-Inspection.
Die einzige Möglichkeit, die mir dazu einfällt ist, dass der Proxy per http angesprochen wird, aber selber auf https weiterleitet. Dazu müsste er also selber die Zertifikatprüfungen übernehmen. Das Transportprotokoll zwischen Browser und Proxy soll aber selber verschlüsselt sein.
Welche Lösungen gibt es da? Was ist das bestgeeignete Proxy-Protokoll? socks, http(s)?
Gruß
HTTP(S)-Proxy zum Caching, auch mit SSL
Re: HTTP(S)-Proxy zum Caching, auch mit SSL
Ich habe mal irgendwo gelesen, dass es Netzwerkkomponenten (Cisco?) gibt, die sowohl Datenpakete komprimieren und bei Wiederholung cachen können. Dabei ist es egal ob die Daten unverschlüsselt oder als verschlüsselt vorliegen, da einzelne Fragmente gecacht werden.
Aber eigentlich rate ich dir davon ab. Niemand muss heute noch cachen. Und vor allem was bringt es dir wenn irgendeine statische Seite gecacht wird aber der Anwender die Internetleitung mit HD-Streams von Youbube auslastet. Da kannst du besser das Geld und die Stromkosten für einen Squid oder ähnliches einsparen und in eine ordentliche Internet-Anbindung investieren.
Wenn es wirklich nur wenige aber große Daten sind könntest su vielleicht über einen Mirror spiegeln. Aber das wäre natürlich was ganz anderes.
Deep-Packet-Inspection ist vielleicht ein Traum und hilft ein wenig. Ähnlich wie Virenscanner. Notwendig aber nicht ausreichend. Spendiere besser allen Anwendern eine eigene VM als Browser und lass das ganze Internet einfach nur dort zu.
Aber eigentlich rate ich dir davon ab. Niemand muss heute noch cachen. Und vor allem was bringt es dir wenn irgendeine statische Seite gecacht wird aber der Anwender die Internetleitung mit HD-Streams von Youbube auslastet. Da kannst du besser das Geld und die Stromkosten für einen Squid oder ähnliches einsparen und in eine ordentliche Internet-Anbindung investieren.
Wenn es wirklich nur wenige aber große Daten sind könntest su vielleicht über einen Mirror spiegeln. Aber das wäre natürlich was ganz anderes.
Deep-Packet-Inspection ist vielleicht ein Traum und hilft ein wenig. Ähnlich wie Virenscanner. Notwendig aber nicht ausreichend. Spendiere besser allen Anwendern eine eigene VM als Browser und lass das ganze Internet einfach nur dort zu.
Re: HTTP(S)-Proxy zum Caching, auch mit SSL
Hatte ich auch mal für den privates Netz in Erwägung gezogen, uname riet kurz und knackig: "Endgeräte sauber halten!" Geht wohl nur im eigenen Netzwerk einfach.weedy hat geschrieben:Zusätzlich will ich eine aktive Introspektion oder Deep-Packet-Inspection.

Falls du ein Firmennetzwerk mit Win-Clients betreust, Traffic entsprechend Inhalt prüfen oder gar verbieten willst:
http://wiki.squid-cache.org/Features/HTTPS
http://wiki.squid-cache.org/ConfigExamp ... mpExplicit
https://turbofuture.com/internet/Interc ... in-pfSense
oder per UTM-Firewall (Untangle, Sophos, PFSense mit Squid, Hardware Appliances der üblichen Verdächtigen)
"https interception bumping" sind so Suchworte für Proxies. UTM (Unified Thread Management) eher ein Marketing-Begriff: Firewall mit Proxy und Paket-Inspektion und Virenscanner, Mail-Pruefung etc.
In Firmen werden häufig auch dedizierte Proxys mit Cache und Nutzerverwaltung genutzt, gibt auch was von Microsoft. Viele Freaks im PFSense- und OpnSense-Forum nutzen das squid-Zusatzpaket wohl auch privat. Freaks halt.
Achtung:
Datenschutzrecht bei DPI außerhalb des eigenen privaten NWs beachten!
Ungültige Zertifikate kriegt der Browser m. E. auch nicht mehr mit, dürfte ja das vom Proxy erhalten.
Re: HTTP(S)-Proxy zum Caching, auch mit SSL
Kann man gerne machen. Ist auch nicht viel anders als ein Man-in-the-Middle-Angriff, der eigentlich bei TLS nicht funktioniert. Der Zweck heiligt scheinbar die Mittel.
Nachtrag siehe 1:
[1] https://www.heise.de/security/artikel/E ... 09009.html
Nachtrag siehe 1:
Bezieht sich eigentlich auf Windows-AV-Software aber prinzipiell identisch. Auch ohne Windows lohnt es den Artikel zu lesen. Wer jedoch Sicherheitsmechanismen aushebelt um angeblich neue zu erzeugen handelt grob fahrlässig.Kaputte Man-in-the-Middle-Module brechen die Sicherheit von TLS und so weiter und so fort.
[1] https://www.heise.de/security/artikel/E ... 09009.html