HTTP(S)-Proxy zum Caching, auch mit SSL

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
Benutzeravatar
weedy
Beiträge: 585
Registriert: 02.11.2002 21:47:49
Lizenz eigener Beiträge: GNU General Public License
Kontaktdaten:

HTTP(S)-Proxy zum Caching, auch mit SSL

Beitrag von weedy » 27.01.2017 19:28:41

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ß

uname
Beiträge: 12072
Registriert: 03.06.2008 09:33:02

Re: HTTP(S)-Proxy zum Caching, auch mit SSL

Beitrag von uname » 28.01.2017 08:33:29

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.

BenutzerGa4gooPh

Re: HTTP(S)-Proxy zum Caching, auch mit SSL

Beitrag von BenutzerGa4gooPh » 28.01.2017 11:28:29

weedy hat geschrieben:Zusätzlich will ich eine aktive Introspektion oder Deep-Packet-Inspection.
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. :wink:

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.

uname
Beiträge: 12072
Registriert: 03.06.2008 09:33:02

Re: HTTP(S)-Proxy zum Caching, auch mit SSL

Beitrag von uname » 29.01.2017 10:43:07

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:
Kaputte Man-in-the-Middle-Module brechen die Sicherheit von TLS und so weiter und so fort.
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.

[1] https://www.heise.de/security/artikel/E ... 09009.html

Antworten