PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Linux Proxyserver Probleme mit Facebook und Youtube



Elma
31.07.16, 13:24
Hallo.

Um die "Gefühlte" Internet-Geschwindigkeit zu verbessern, und weniger Traffic zu verursachen, würde ich gerne eine Proxyserver installieren, der auch Facebook (Inklusive Pinnwand-Videos und FB-Spielen) und Youtube Inhalte cached.

Diese Seiten laufen ja heute weitgehend über HTTPS, so dass man einen HTTPS Proxy einrichten muss, und das selbst erzeugte Zertifikat im Browser als vertrauenswürdiges Zertifikat ablegen muss.

Soweit so gut. "Einfache" Seiten, die nur über Port 443 angebunden sind, also viele Foren/Webseiten bei "Standardhostern" werden auch gecached.

Bei Facebook oder Youtube erfolgt leider kaum ein Caching. Gerade das, worauf es ankommt, wie z.B. Facebook-Flash Spiele oder Videos bei YT / FB, weil Traffic-hungrig, wird einfach nicht gecached.

Woran könnte das liegen?

florian0285
31.07.16, 15:13
Ein paar Eckdaten wären gut zu wissen.

BetterWorld
31.07.16, 17:42
Da gäbe es viele Antworten zu schreiben.
Zum einen lassen Headers in HTML bereits die Steuerung von Caching zu,
zum anderen verwendet das moderne Web Websockets.
Das sind im Prinzip Peer-to-Peer Verbindungen, die in Echtzeit kommunizieren.

Der herkömmliche Proxyansatz läuft da in's Leere.

Außerdem kann ein vernünftiger Proxy SSL/TLS Connections terminieren.
Es ist dann nicht nötig mit selbst gebastelten Zertifikaten rumzuspielen.
Will man dennoch (aus welchen Gründen auch immer) eine durchgehende TLS Verschlüsselung, sollte man statt selbtgebastelten Certs schlicht Letsencrypt bemühen.

Moderne Websites wollen Echtzeitkommunikation.
Viele schnelle Websites setzen dafür auch Servermodule, wie z.B. PageSpeed ein.
Zusammen mit HTML2.x laden solche Webseiten schneller, als man es auf herkömmlichen Wege mit einem Proxy hinkriegen kann.

Mit einem Proxy wirst du nur bei altbackenen Webseiten Erfolg haben.
Google und Facebook gehören sicher nicht dazu.
Und machst du das wirklich gut und rigoros, behaupte ich, dass die dann sogar signifikant langsamer sind.

Meine Empfehlung: Lass es einfach.

florian0285
31.07.16, 19:10
Wenn du keine selbst gebastelten Zertifikate benutzt bekommst du Probleme mit HSTS. Ich lass mir aber auch gern zeigen, dass ich falsch liege. Bei der Geschwindigkeit und Co geb ich dir recht. Das ganze wäre nur sinnig, wenn er die Bandbreite damit reduzieren möchte wegen eines Volumentarifs oder ähnlichem.

Ohne Eckdaten -> keine Hilfe.

BetterWorld
31.07.16, 20:15
Wenn du keine selbst gebastelten Zertifikate benutzt bekommst du Probleme mit HSTS.Das ist falsch. Da die Certs von Letsencrypt von jedem Browser mittlerweile akzeptiert werden, geht das ohne Probleme.
Natürlich muss das ganze Zeugs in sich stimmig und korrekt aufgesetzt werden, was eigentlich immer die Norm sein sollte.
Ich setze das mit nginx ein und habe hinter der TLS - Strecke einige Proxies und/oder irgendwelche uWSGIs laufen. Teile davon sind plain HTTP, manche durchgängig HTTPS.
Und das klappt prima mit restriktiven HSTS Headern und Letsencrypt.

Mit ein paar Serverdirektiven lädt der Browser alles, auch Cookies, via TLS (ohne auf der preload Liste zu stehen).

florian0285
31.07.16, 21:50
ok dann habe ich das erstmal so verstanden, dass du hinter deinem proxy alles unverschlüsselt lässt.

Du ersetzt quasi nur die selbst gebastelte variante nur mit letsencrypt.
Dann gibts natürlich keine Probleme.

Was stört dich denn an selbst gebasteltem?

BetterWorld
31.07.16, 22:00
ok dann habe ich das erstmal so verstanden, dass du hinter deinem proxy alles unverschlüsselt lässt.

Du ersetzt quasi nur die selbst gebastelte variante nur mit letsencrypt.
Dann gibts natürlich keine Probleme.

Was stört dich denn an selbst gebasteltem?Nein.
Du verstehst halt einfach nur falsch.

Der erste nginx ist ein Reverseproxy. Der liefert an den Browser aus und hat die Certs von Letsencrypt.
Da werden die TLS dann terminiert, oder halt auch nicht.

Von dort geht es dann entweder zu einem weiteren nginx, oder via uWSGI zu einer app.
(Oder zu einem weiteren nginx und dann zu uWSGI zur app)

Beide Strecken kann ich entweder mit TLS oder ohne betreiben.
Der Client merkt davon genau gar nix.
Der Reverseproxy an der Front das erledigt.

Und selbstgebastelte Certs triggern IMMER eine Warnung und der User muss sie händisch importieren.
Das ist einfach nicht mehr nötig seit es Letsecrypt gibt.

Es war noch nicht einmal vor Letsencrypt nötig.
Es gab schon da startssl und noch ein paar, die kostenlose Certs anboten,
die klaglos akzeptiert wurden, weil deren CA allen Browsers bereits bekannt war.
(Ich hatte vorher auch startssl)

Das Selberbasteln von Certs sollte man schon einmal machen.
Aber, um es zu lernen, ganz sicher nicht, um sie einzusetzen.

florian0285
31.07.16, 22:53
Nein jetzt verstehst du mich falsch [emoji12]

Das erste mal hab ich verstanden, dass du alles unverschlüsselt lässt. Da Terminieren beenden bedeutet. Das was du beim zweiten mal beschreibst ist aufbrechen und unter SSL-Scanning bekannt was wir in einer professionelleren Variante auch einsetzen.

Sprich der Browser bekommt sein ssl, er bekommt bei dir nur sein letsencrypt zertifikat vorgegaukelt.

Bei deinem Konzept hätte ich Datenschutzrechtliche bedenken, wenn du das im Unternehmen so betreibst. Die Auswertung des Contet darf ausschließlich automatisiert erfolgen sprich der Admin darf nicht rein gucken. Zumindest hat mir noch keiner das Gegenteil bewiesen [emoji12] aber ich weiß ja nicht wer dir alles seine Seele verkauft hat. Ich würde es an deiner Stelle trotzdem nochmal rechtlich prüfen bevor du vor den Kadi gezogen wirst. Und wenn ich nginx lese denke ich da sofort daran, dass da irgendwo was einsehbar zwischengespeichert wird.

SartSSL kenn ich, hab ich 2006 mal benutzt. Da gabs aber auch Probleme mit unbekannten Zertifikaten etc. Is aber schon 10 Jahre her, vielleicht haben sie ja dazugelernt.
Kostenlose Zertifikate sind ne tolle Sache, wenn man öffentlich auftritt. Intern spricht aber nichts gegen selbst erstellte. Da umgeht man Sicherheitsprobleme wie beim Fall Digi-Notar von haus aus. Es gibt bei letsencrypt auch keine wildcard zertifikate also bleibt mir nur meine eigene ca oder ich bezahle dafür.
Grundsätzlich ist das aber immer ein Abwägen des Verhältnisses zwischen Nutzen und Aufwand. Ab einer gewissen Größe lohnt sich der Aufbau einer internen PKI Struktur. Also die Bastelvariante kann man auch professionell aufziehen. Anders machts letscrypt ja auch nicht. Die Verteilung der CA Zertifikate geht auch simpel über ne AD.

Nachtrag:

zur Info:

Dies erfordert zunächst die Vermeidung von möglichen Straftatbeständen

- § 202a StGB, Ausspähen von Daten,

- § 206 StGB, Bruch des Fernmeldegeheimnisses,

- Ordnungswidrigkeit nach § 43 BDSG.

Insbesondere darf der Scanvorgang nicht zur Kenntnisnahme der Inhalte führen, muss also in einer Blackbox ablaufen.

Das mit nginx umzusetzen ist auf den ersten Blick nicht möglich.

ThorstenHirsch
01.08.16, 00:06
[...BDSG...]
Das mit nginx umzusetzen ist auf den ersten Blick nicht möglich.
Das BDSG ist ein Segen für alle, die Argumente dafür brauchen, warum irgendwas nicht möglich ist. :rolleyes:

florian0285
01.08.16, 00:18
Ja es ist ein Technik verhinderer.
Aber bei Überwachung berufen sich komischer Weise immer alle darauf. [emoji12]

Nichts desto trotz ist es da und muss umgesetzt werden. Für eine Firma, die das ignoriert wär das schon fahrlässig. Immerhin ist das nach den Steuern, Diäten und Wahlstimmen das Wertvollste gut [emoji38]

nopes
01.08.16, 01:47
Mal ganz davon ab, https und Proxy sind nicht vereinbar. HTTP ist tot, wirklich schwer da noch eine Berechtigung herbei zu argumentieren, oder anders: jeder neue Dienst muss doch verschlüsselt kommunizieren. Proxies sind tot, ein klassischer Proxy-Server macht idR einfach keinen Sinn mehr, dass kann man gut finden oder auch nicht, ist aber (leider) so.

marce
01.08.16, 06:46
Proxies sind tot, ein klassischer Proxy-Server macht idR einfach keinen Sinn mehr
Einschränkung: Zumindest auf der Client-Seite der Verbindung.

florian0285
01.08.16, 08:15
Ich finde HTTP durchaus noch nutzenswert. Unkritische Seiten wie Tageszeitung, Wetterinfo oder ne einfache Firmenpräsentation müssen aus meiner Sicht nicht verschlüsselt werden. Jede Verschlüsselung kostet Ressourcen und erhöht in der Masse Strom, Kosten und Emissionen. Bei uns gibt es noch Volumentarife oder flexible Bandbreitenabhängige Tarife. Wenn ich meine 1 Mio Bild.de Anfragen früh morgens dann cachen kann, weil jeder nur die Startseite liest spart das auch wieder oben genannte Dinge. In der dritten Welt lohnt sich ein Proxy alle mal und Diktaturen profitieren auch von unverschlüsseltem Traffic [emoji12]


Aber mal davon abgesehen, steht das ursprüngliche Thema noch im Raum?

marce
01.08.16, 08:42
:-) überleg doch einfach mal, welche Profildaten man aus der Lektüre von Tageszeitung, Wetterinfo und Firempräsentationen herauslesen kann :-)

Grundlegend gilt heute leider: Je mehr Verschlüsselung desto besser. Bei aktuellen CPUs macht das auch im großen und ganzen keinen Unterschied mehr was die Leistungsanforderung angeht - wenn's daran liegt daß ein Server an sein Grenzen kommt war er es davor eigentlich auch schon...

florian0285
01.08.16, 09:25
Naja wie gesagt mit SSL Scanning geht das auch, wenn man wollte. Und Profildaten muss man ja nicht zwangsläufig eingeben. Wenn da dann nur die üblichen Firmendaten erkennbar sind kennt die der Arbeitgeber eh schon. Wer sein Tagebuch auf Bild.de ablegt ist selber Schuld und so gesehen brauche ich ja keine dynamischen Inhalte, Cookies, JS etc. um mir die Temperatur und den 3 Tagetrend anzeigen zu lassen. Aber das wär dann ja altmodisch.

Das mit den Ressourcen war auf das Gesamtsystem Internet bezogen. Wenn jeder Admin nur etwas an der Sparschraube drehen würde könnte man genug einsparen. Die Ressourcen müssen ja auch nicht ausgelastet sein, damit ich einen Sparsinn entwickle. Allein das automatisierte Herunterfahren zum Feierabend z. B. wäre schon ein Anfang. Nur bei 90% läuft die Kiste rund um die Uhr weil nachts 3 Minuten update gefahren wird. Bei manchen muss es vielleicht durchlaufen, bei vielen nicht. Und jetzt schweif ich ab... [emoji38]
Egal ob das was für nein kleines System etwas bring 1 Mio x 1 mW im Jahr ist auch ein AKW oder Kohlekraftwerk zu viel.

marce
01.08.16, 09:35
ich meinte nicht diese Profildaten. Sondern das, was sich aus Metadaten heraus als "Benutzerprofil" erstellen lässt. Und dann sind wir be durchaus interessanten Infos, die über kurz oder lang zu einem sehr interessanten Datenpaket...

... und ja, mit SSL wird's nicht unmöglich - aber ggf. so schwer, daß sich für Massen-Jobs der Aufwand nicht mehr lohnt.

florian0285
01.08.16, 18:09
Hmm ok aber was soll mein arbeitgeber dann von mir denken, wenn er die daten auswertet?

marce
01.08.16, 18:30
Nicht nur dein Arbeitgeber. Aber viele andere "im Netz" leben davon, solche Daten zu erfassen, zu kombinieren und dann über die entsprechenden Profile Geld mit Dir zu verdienen. Sogar ohne, daß Du es weißt oder mitbekommst.

BetterWorld
01.08.16, 19:01
Du verstehst es noch immer nicht.

Und mit weiteren von sehr, sehr weit hergezogenen Scheinargumenten versuchst du irgendwie irgendwas.

Das Argument, dass eine eigene PKI letsencrypt gleichen würde, mag schon sein.
Dass die Certs von Letsencrypt in den Browsern dabei sind, die Certs privater PKIs nicht, bleibt.
Da kannst du argumentieren, wie du willst.
Es ist für die User eine blödes Erlebnis vom Browser vor einer unsicheren Verbindung, die eigentlich (relativ) sicher ist, gewarnt zu werden.
Unprofessionell.

Ich betreibe kein SSL- Scanning.
Ich habe lediglich einen Proxy, der TLS sauber terminieren kann.
Das tut er, oder nicht.
Je nach Domain, Zweck und all dem Kram, der dahinter läuft, oder halt auch nicht.

Ich kann damit AUCH durchgängig verschlüsselten Verkehr weiterreichen.

Den Browsers gaukle ich gar nichts vor.
Für jede Subdomain gibt es ein Cert von Letsencrypt.
Und die tun gut.

Ich würde fast behaupten wollen, dass du noch nie einen nginx sauber aufgesetzt hast.
Was du da erzählst, ist weit ab.

Und das Argument, dass Nichtverschlüsselung Strom sparen würde,
ist einfach nur kindisch.
Wir würden uns auch einen Haufen Erdöl sparen, wenn wir keine Autos hätten.
Zumal bei modernen Maschinen und Algos -wie Marce schon schrieb- das wohl zu vernachlässigen ist.

Dein unzulässiges Argument, dass Datenschutzgesetze das illegitimieren würde, ist dann nur noch Banane.
Zum einen gewährleiste ich erst durch meinen Setup einen gewissen Schutz.
Zweites biete ICH die Inhalte.
Nach deinem völlig danebenliegenden Argument, dürfte ich ja dann nicht einmal wissen, was ich anbiete.
Einfach nur krank.

In extremo dürften egal welche Daten nur noch verschlüsselt in egal welchem RAM verarbeitet werden.
Spätestens jetzt sollte dir aufgehen, dass das kompletter Unsinn ist.

marce
01.08.16, 19:20
Es ist durchaus ein Unterschied, ob die Daten im Client entschlüsselt werden oder in irgendeinem, vom User nicht zu kontrollierenden Proxy in der Übertragungskette.

Ein Proxy, der https entschlüsselt und nach innen neu verschlüsselt weiter gibt ist ein MITM - und damit aus User-Sicht ein Risiko für Datensicherheit und je nach Nutzungs-Vereinbarung ein Eingriff in die Privatsphäre des Nutzers. Und verstößt damit ggf. gegen div. Gesetze.

BetterWorld
01.08.16, 19:28
Das ist rein technisch gesehen richtig.

Nur läuft das Argument dennoch in's Leere,
da alles auf einem Server läuft.
Aber selbst wenn ich dahinter noch weitere Server betreiben würde,
ist das Argument immer noch nicht zulässig.
Ich als Anbieter mache das.
Und kann deshalb per definitionem kein Man-in-the-middle sein.

Andernfalls dürfte in einem Firmennetzwerk nichts entschlüsselt werden, was vom Kunden stammt.
Und dann, wenn es am Endpunkt der Verarbeitung doch entschlüsselt wurde, darf es nicht wieder verschlüsselt werden, weil ja sonst wieder MITM.

Die Debatte geht insgesamt am Problem vorbei.
Solch radikale Auslegungen schwächen die Sicherheit enorm.
Ich halte diese Auslegung für nicht zulässig und nicht zutreffend.

marce
01.08.16, 19:40
Nein, es geht nicht am Problem des TE vorbei - der will bei sich im Netz einen Proxy einbauen, der auch https entschlüsseln kann (neben den div. anderne problem. Dingen wie Videos und Konsorten) - und damit ist er nicht Anbieter sondern für alle, die bei ihm im Netz surfen ein MITM - und das ist alles mögliche, nur nicht legal.

Das hat rein gar nichts damit zu tun, daß Server "hinten rum" miteinander verschlüsselt kommunizieren und die Ergebnisse (oder sogar komplette Teile) der Kommunikation zum Client durchgeschleift werden.

Rumdiskutieren kann man viel - aber es sollte doch wenigstens zum Ursprungsproblem passen. Und ja, es mag sein daß derlei Bedenken im privaten Bereich womöglich an der Thematik vorbei sind (oder gerade dort besonders beachtet werden sollten - abgesehen davon, wie man es trotz allem technisch sauber hinbekommt). Erwähnen sollte man sie trotzdem.

florian0285
01.08.16, 19:44
Nicht nur dein Arbeitgeber. Aber viele andere "im Netz" leben davon, solche Daten zu erfassen, zu kombinieren und dann über die entsprechenden Profile Geld mit Dir zu verdienen. Sogar ohne, daß Du es weißt oder mitbekommst.

Richtig aber SSL sorgt hier ja nur für den Transport der Daten. Wenn Bild.de diese verwerten möchte können die das mit oder ohne Verschlüsselung. Und in meinem privaten Netz betreibt mein Arbeitgeber ja kein SSL Scanning [emoji51] Also entweder reden wir aneinander vorbei oder ich versteh grad nicht wie du das meinst.

@BetterWorld du bist schon wieder so weit, dass du beleidigend wirst. Wenn du meinst... dann ignoriere geltendes Recht. Terminieren ist nicht durchreichen! Ich kenn dein Netz nicht und mit den Bröckchen, die da um dich wirfst sieht das nicht gesetzeskonform aus! Immerhin gehts hier um Proxys. Asynchrone Verschlüsselungsalgorithmen haben bewiesener Maßen eine höhere Komplexitätsklasse als garkeine, dazu muss man nur mal das Hirn einschalten um das zu verstehen. Somit mehr Laufzeit, somit mehr CPU lasst, somit mehr Strom. Für einen einzelnen PC mit nginx mag das nicht relevant sein, aber 100.000 Rechner kann man dann schon in ein paar W umrechnen. Und jetzt behaupte nicht, dass es so große Netze nicht gibt. Mir scheint du hast dich mit PKI noch nie wirklich beschäftigt, sonst könntest du Kosten/Nutzen/Aufwand abwägen. Drück meinetwegen auf den "generate SSL Certi" Button [emoji6] du verstehst entweder nicht was in deinem Netz vor geht oder kannst dich nicht verständlich ausdrücken. Kann mir aber auch egal sein, weil du den Bockmisst im Zweifelsfall baust. Von RAM verschlüsseln hat niemand was gesagt... es darf nur niemand Einsicht haben. Wenn du dir darunter nichts vorstellen kannst erlerne einen anderen Beruf.
Ich hatte dir einen Tipp gegeben, da du eine rechtliche Gratwanderung machst, wenn dein System wie beschrieben funktioniert. Das könnte man dankend annehmen oder so wie eben respektlos abschmettern. Auch wenn es bereits so laufen würde, dass es passt...

Möge das Karma dich heimsuchen...

Und nein von dir ist keine Antwort an mich erwünscht. Wenn der TE eine Frage an dich hat wird er sie bestimmt stellen.

Die Kernaussage war ursprünglich für den TE:

Selbst gebastelte Certs sind auch ok, man muss die nur an die Clients verteilen. Das geht sehr bequem über Gruppenrichtlinien.

Letsencrypt geht dafür auch und wurde nie angezweifelt.

Und da er sich nicht mehr meldet is das Thema wohl durch und kurz vor ner Zwangsschließung [emoji12]

BetterWorld
01.08.16, 19:44
Ich denke für den Threadersteller ist das längst geklärt.

Zudem glaube ich, dass das eher privat war. Er hat jedenfalls nichts von alldem geschrieben.
Das kam erst mit dem unzulässigen Rummäkeln.

marce
01.08.16, 20:05
Richtig aber SSL sorgt hier ja nur für den Transport der Daten.
Genau. Solange der Transport verschlüsselt ist kann nur Anbieter und Kunde die Kommunikation "analysieren" und aus den gelieferten Daten einen Mehrwert generieren.

Wenn aber der Transport nicht verschlüsselt ist - kann das jeder. Und dann kann eben auch dieser jeder eben den Mehrwert nicht nur aus der Kommunikation von Kunde mit Server A generieren sondern auch aus der mit Server B, C, ...

Deswegen - und nur deswegen, weil eben im Netz grundsätzlich erst mal niemand vertrauenswürdig ist, sollte jede Kommunikation verschlüsselt stattfinden. Und deswegen sind SSL aufbrechende Proxies auf Clientseite bzw. aus Clientsicht ein NoGo.

florian0285
01.08.16, 20:05
Ursprünglich war ich ganz höflich und habe auf Probleme mit HSTS hingewiesen und auf EVENTUELLE Konflikte mit geltendem Recht hingewiesen. Rumäkeln ist der falsche Ausdruck dafür [emoji6]
Ich biete dir die Möglichkeit die Differenzen der letzten Tage zivilisiert hier und jetzt beizulegen und in zukünftigen Antworten zu bestimmten Themen einfach nur noch sachlich und emotionslos zu beantworten, falls wir im selben Thread landen. Und jetzt bin ich hier raus bevor die Mailbox des TE's voll läuft. Der futtert bestimmt schon sein Popcorn beim Lesen [emoji12]

@marce ja aus der Sicht hast du recht. Diese ganze SSL-Scanning Geschichte ist ja nur rechtskonform, da man hier eigentlich nur vor dem Schutz von Schadcode schützen möchte. Ich seh das persönlich nur nicht so eng mit unverschlüsselten Seiten. Manchmal gefällt mir die maßgeschneiderte Werbung ja. Aber wie gesagt bevor das hier zu OffTopic wird oder ich wieder den Bärentöter raus hole bin ich raus...