Squid Cache mehrstufig

[Tim Ritberg]

Hi!

Wie kann ich Squid3 mehrstufig einstellen?
Generelle Anfragen soll auf einen Cache gehen, der in einer Ramdisk
liegt und Anfragen an Debian/Ubuntu Paketrepository an einen Cache auf
Platte.

Tim

--
Xubuntu 18.04 64 bit, Kernel 4.15
ASRock Z77 Extreme4, 24 GB RAM, i7 3770

[Kay Martinen]

Am 16.06.2018 um 14:14 schrieb Tim Ritberg:

>
> Wie kann ich Squid3 mehrstufig einstellen?
> Generelle Anfragen soll auf einen Cache gehen, der in einer Ramdisk
> liegt und Anfragen an Debian/Ubuntu Paketrepository an einen Cache auf
> Platte.

Wie man das händisch machen könnte weiß ich auch nicht. Aber ganz
einfach geht es mit

IPFIRE: Update-Accelerator aktivieren.

Obiges hat bei mir eigentlich super funktioniert. Man muß den internen
Hosts lediglich beibringen das apt den proxy benutzen soll. Und Für
Windows macht der das auch gleich mit.

IMHO steckt da auch "nur" ein Squid hinter. Dessen Konfig müßte man mal
abgreifen - was dank linux und shell Zugang kein Problem sein müßte.

Ich hab da zwar eine Ipfire VM (momentan aus) die ich derzeit aber nicht
produktiv nutze. Aber wenn du dir nicht selbst eine Einrichten willst,
sag Bescheid dann schaue ich mal wo und wie ich da was raus finde.

Kay

--
Sent via SN (Eisfair-1)

[Tim Ritberg]

Am 16.06.2018 um 16:36 schrieb Kay Martinen:
> Am 16.06.2018 um 14:14 schrieb Tim Ritberg:
>
>>
>> Wie kann ich Squid3 mehrstufig einstellen?
>> Generelle Anfragen soll auf einen Cache gehen, der in einer Ramdisk
>> liegt und Anfragen an Debian/Ubuntu Paketrepository an einen Cache auf
>> Platte.
>
> Wie man das händisch machen könnte weiß ich auch nicht. Aber ganz
> einfach geht es mit
>
> IPFIRE: Update-Accelerator aktivieren.

Auf der Arbeit hab ich dafür squid-deb-proxy.

Sowas löst das Problem aber nicht.

Tim

[Holger Marzen]

* On Sat, 16 Jun 2018 14:14:33 +0200, Tim Ritberg wrote:

> Wie kann ich Squid3 mehrstufig einstellen?
> Generelle Anfragen soll auf einen Cache gehen, der in einer Ramdisk
> liegt und Anfragen an Debian/Ubuntu Paketrepository an einen Cache auf
> Platte.

Mein Squid-Wissen ist schon sehr angestaubt. Was auf jeden Fall gehen
muss:

Mit den Clients gehst Du zuerst auf einen Squid, der den Cache auf
Ramdisk hat. Der ist so eingestellt, dass er nur kleine Dateien
überhaupt cacht. Dieser Squid geht zu einem weiteren Squid, der den
Cache auf Platte hat und auch sehr große Dateien cacht.

Dann cacht der Squid mit dem Platten-Cache auch kleine Dateien, aber das
tut ja nicht weh.

[Tim Ritberg]

Am 16.06.2018 um 19:43 schrieb Holger Marzen:
>
> Mein Squid-Wissen ist schon sehr angestaubt. Was auf jeden Fall gehen
> muss:
>
> Mit den Clients gehst Du zuerst auf einen Squid, der den Cache auf
> Ramdisk hat. Der ist so eingestellt, dass er nur kleine Dateien
> überhaupt cacht. Dieser Squid geht zu einem weiteren Squid, der den
> Cache auf Platte hat und auch sehr große Dateien cacht.

Die Idee mit mehreren Squid-Instanzen hatte ich auch schon (tm).
Finde ich aber uncool ;-)


Tim

[Holger Marzen]

Pack sie in Docker-Container, dann ist es cool :)

[Friedemann Stoyan]

Tim Ritberg wrote:

> Generelle Anfragen soll auf einen Cache gehen, der in einer Ramdisk
> liegt und Anfragen an Debian/Ubuntu Paketrepository an einen Cache auf
> Platte.

Finde ich vergebliche Liebesmüh. Der größte Teil der Verbindungen dürfte heute
SSL sein. Da gibt es nichts zu cachen.

mfg Friedemann

[Tim Ritberg]

Am 16.06.2018 um 21:02 schrieb Friedemann Stoyan:

>
> Finde ich vergebliche Liebesmüh. Der größte Teil der Verbindungen dürfte heute
> SSL sein. Da gibt es nichts zu cachen.
>
> mfg Friedemann
>

Für Linuxpakete stimmt das nicht.

Tim

[Kay Martinen]

Du meinst 'apt-key' (oder wie das genau heißt) braucht die schlüssel nur
zur paketvalidierung und um sicher zu gehen das der update-server auch
wirklich der update-server ist - aber nicht zur Verschlüsselung einer
https-verbindung?

Das wäre cool. Dann geht das cachen damit ja weiterhin.

[Tim Ritberg]

Am 16.06.2018 um 23:18 schrieb Kay Martinen:

> Du meinst 'apt-key' (oder wie das genau heißt) braucht die schlüssel nur
> zur paketvalidierung und um sicher zu gehen das der update-server auch
> wirklich der update-server ist - aber nicht zur Verschlüsselung einer
> https-verbindung?
>

https://debian-handbook.info/browse/de-DE/stable/sect.package-authentication.html

Tim

[Friedemann Stoyan]

Tim Ritberg wrote:

>>
>> Finde ich vergebliche Liebesmüh. Der größte Teil der Verbindungen dürfte heute
>> SSL sein. Da gibt es nichts zu cachen.
>>

> Für Linuxpakete stimmt das nicht.

Das weiss ich. Darum ging es auch gar nicht. Es ging mir um die
"Mehrstufigkeit". Ich halte es halt für Quatsch, da viel Arbeit reinzustecken.
Normales Browsing, gefühlt 90% SSL geht nicht in den Cache. Debian Pakete aber
schon, solange ohne SSL zugegriffen wird. Da kann man noch etwas mit
"refresh_patterns" dran tunen und das war es dann:

# Debian Archives
# Index (Dynamic contents, 6 Hr. = 360 Min.)
refresh_pattern -i debian\.org.*Release$ 0 41% 360
refresh_pattern -i debian\.org.*Packages\.gz$ 0 41% 360
refresh_pattern -i debian\.org.*Packages\.bz2$ 0 41% 360
refresh_pattern -i debian\.org.*Sources\.gz$ 0 41% 360
refresh_pattern -i debian\.org.*Sources\.bz2$ 0 41% 360
# Archive (Static contents, 1 Yr. = 525600 Min. Non-HTTP-Standard)
refresh_pattern -i debian\.org.*\.orig\.tar\.gz$ 525600 80% 525600 ignore-reload reload-into-ims
refresh_pattern -i debian\.org.*\.diff\.gz$ 525600 80% 525600 ignore-reload reload-into-ims
refresh_pattern -i debian\.org.*\.deb$ 525600 80% 525600 ignore-reload reload-into-ims
refresh_pattern -i debian\.org.*\.udeb$ 525600 80% 525600 ignore-reload reload-into-ims
refresh_pattern -i debian\.org.*\.dsc$ 525600 80% 525600 ignore-reload reload-into-ims

Eventuell noch etwas an den Objekt-Größen manipuieren:

cache_mem 1024 MB
maximum_object_size_in_memory 4 MB
cache_replacement_policy heap LFUDA
maximum_object_size 128 MB
cache_dir aufs /var/spool/squid 5120 16 256

Viel mehr würde ich nicht tun.


mfg Friedemann

[Ralph Aichinger]

Friedemann Stoyan <use...@ip6-mail.de> wrote:
> Normales Browsing, gefühlt 90% SSL geht nicht in den Cache. Debian Pakete aber

Nach Zahlen von Google 68% des Chrome-Traffics unter Android und Windows
und über 78% des Chrome-Traffics unter Chrome-OS und Mac.

Und bei Chrome 70 wird die Schraube noch mal weiter zugedreht werden,
es ist nicht anzunehmen, daß dann irgendwas außer ungewarteten Altlasten
noch HTTP only geserved wird.

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund

[Holger Marzen]

* On Sun, 17 Jun 2018 07:51:54 +0200 (CEST), Ralph Aichinger wrote:

> Friedemann Stoyan <use...@ip6-mail.de> wrote:
>> Normales Browsing, gefühlt 90% SSL geht nicht in den Cache. Debian Pakete aber
>
> Nach Zahlen von Google 68% des Chrome-Traffics unter Android und Windows
> und über 78% des Chrome-Traffics unter Chrome-OS und Mac.
>
> Und bei Chrome 70 wird die Schraube noch mal weiter zugedreht werden,
> es ist nicht anzunehmen, daß dann irgendwas außer ungewarteten Altlasten
> noch HTTP only geserved wird.

Leute, die sich dem SSL-Zensurwahn nicht beugen, kommen auch noch dazu.
Irgendwie scheint es keiner zu merken:

- SSL wird selbst für Lieschen Müllers Blumenseite als unbedingt
notwendig postuliert
- Gleichzeitig wird ständig an den SSL-Implementierungen von Browsern
herumgespielt und „unsichere“ Verfahren einfach restlos entfernt, was
zum DoS führt, wenn sie Seitenbetreiber nicht brav übers Stöckchen
springen
- CAs kommen und gehen in den Browsern.
- Selbstsignierte Zertifikate werden systematisch diskreditiert und von
den üblichen MITM-Geräten vieler Firmen und Institutionen als unsicher
blockiert – selbst wenn SSL-Verbindungen aufgebrochen werden
- Initiativen wie Let’s Encrypt stellen kostenlose Zertifikate mit
lächerlich geringer Laufzeit aus, was doch sehr an das Anfüttern durch
Dealer oder Mobilfunk- und Internet-Verträge der Art „0,00 EUR (die
ersten drei Monate)“ erinnert.

„SSL überall“ ist auf dem Weg, zum Zensur- und Sabotagemittel zu werden.

[Holger Marzen]

* On Sun, 17 Jun 2018 07:51:54 +0200 (CEST), Ralph Aichinger wrote:

> Friedemann Stoyan <use...@ip6-mail.de> wrote:
>> Normales Browsing, gefühlt 90% SSL geht nicht in den Cache. Debian Pakete aber
>
> Nach Zahlen von Google 68% des Chrome-Traffics unter Android und Windows
> und über 78% des Chrome-Traffics unter Chrome-OS und Mac.
>
> Und bei Chrome 70 wird die Schraube noch mal weiter zugedreht werden,
> es ist nicht anzunehmen, daß dann irgendwas außer ungewarteten Altlasten
> noch HTTP only geserved wird.

Leute, die sich dem SSL-Wahn nicht beugen, kommen auch noch dazu.

Irgendwie scheint es keiner zu merken:

- SSL wird selbst für Lieschen Müllers Blumenseite als unbedingt
notwendig postuliert
- Gleichzeitig wird ständig an den SSL-Implementierungen von Browsern
herumgespielt und „unsichere“ Verfahren einfach restlos entfernt, was

zum DoS führt, wenn die Seitenbetreiber nicht brav übers Stöckchen

[Ralph Aichinger]

Holger Marzen <hol...@marzen.de> wrote:
> Leute, die sich dem SSL-Wahn nicht beugen, kommen auch noch dazu.

Äh ja, die sind das digitale Gegenstück zu den Zeugen Jehovas die
regelmäßig durch die Städte pilgern, immer paarweise. Man weiß zwar
nicht wofür es gut ist, aber sie machen es.

> Irgendwie scheint es keiner zu merken:
>
> - SSL wird selbst für Lieschen Müllers Blumenseite als unbedingt
> notwendig postuliert

Ja, wenn Lieschen Müllers Blumenseite von Google nicht mit einem
schlechteren Rank abgestraft werden will, dann schon. Wenn Lieschen
Müller zu Jehovas Zeugen gehört, dann ist ihr das natürlich egal.

> - Gleichzeitig wird ständig an den SSL-Implementierungen von Browsern
> herumgespielt und „unsichere“ Verfahren einfach restlos entfernt, was
> zum DoS führt, wenn die Seitenbetreiber nicht brav übers Stöckchen
> springen

Das ist notwendig, weil Downgrade-Attacken kein nur eingebildetes
Problem sind.

> - CAs kommen und gehen in den Browsern.

Ja.

> - Selbstsignierte Zertifikate werden systematisch diskreditiert und von
> den üblichen MITM-Geräten vieler Firmen und Institutionen als unsicher
> blockiert – selbst wenn SSL-Verbindungen aufgebrochen werden

Welchen Grund gibt es statt eines Let's-Encrypt-Zertifikats ein
selbstsigniertes zu verwenden? Wer kompetent mit selbstsignierten
Zertifikaten umgehen kann, der wird dies auch weiterhin clientseitig
sinnvoll implementieren können (durch Hinzufügen eines eigenen Root-
Zertifikats).

Warum das alles irgendwas mit dem Aufbrechen von Verbindungen zu tun
haben sollte ist mir nicht klar. LE macht das aufbrechen eher
schwieriger als leichter, verglichen mit selbstsigniertem.

> - Initiativen wie Let’s Encrypt stellen kostenlose Zertifikate mit
> lächerlich geringer Laufzeit aus, was doch sehr an das Anfüttern durch
> Dealer oder Mobilfunk- und Internet-Verträge der Art „0,00 EUR (die
> ersten drei Monate)“ erinnert.

Nein. LE ist für Cronjobs gedacht.

> „SSL überall“ ist auf dem Weg, zum Zensur- und Sabotagemittel zu werden.

Zeugen Jehovas laufen klingelnd durch die Städte und sehen Probleme
wo keine sind.

[Holger Marzen]

* On Sun, 17 Jun 2018 12:07:47 +0200 (CEST), Ralph Aichinger wrote:

> Holger Marzen <hol...@marzen.de> wrote:
>> Leute, die sich dem SSL-Wahn nicht beugen, kommen auch noch dazu.
>
> Äh ja, die sind das digitale Gegenstück zu den Zeugen Jehovas die
> regelmäßig durch die Städte pilgern, immer paarweise. Man weiß zwar
> nicht wofür es gut ist, aber sie machen es.

Also SSL überall. Ja, da gibt es ein ausgeprägtes Sendungsbewusstsein,
wenn man sieht, wie Du Dich dafür ins Zeug legst und Kritik auf der
persönlichen Ebene angehst.

> Welchen Grund gibt es statt eines Let's-Encrypt-Zertifikats ein
> selbstsigniertes zu verwenden? Wer kompetent mit selbstsignierten
> Zertifikaten umgehen kann, der wird dies auch weiterhin clientseitig
> sinnvoll implementieren können (durch Hinzufügen eines eigenen Root-
> Zertifikats).

Können vor Lachen auf anderer Leute Browser. Dazu kommen Blockierungen
als Standardeinstellung in „Sicherheitslösungen“.

> Warum das alles irgendwas mit dem Aufbrechen von Verbindungen zu tun
> haben sollte ist mir nicht klar. LE macht das aufbrechen eher
> schwieriger als leichter, verglichen mit selbstsigniertem.

Firmen begründen das Blocken von Seiten mit selbstsigniertem Zertifikat
mit angeblichen Sicherheitsgründen. Da SSL-Verbindungen gewohnheitsmäßig
aufgebrochen werden, können diese Verbindungen aber genauso gescannt
werden wie unveschlüsselte. Die Begründung ist daher ein Vorwand. Es
geht darum, selbstsignierte Zertifikate auszumerzen. Gründe dafür mag es
viele geben. Aber keiner hat was mit Sicherheit zu tun.

>> „SSL überall“ ist auf dem Weg, zum Zensur- und Sabotagemittel zu werden.
>
> Zeugen Jehovas laufen klingelnd durch die Städte und sehen Probleme
> wo keine sind.

Abgesehen davon, dass Zeugen Jehovas überzeugt sind, das moralisch
Richtige zu tun, stehen hinter der SSL-Missionierung deutlich niederere
Beweggründe. Rechthaberei und mangelnde Weitsicht sind noch die
harmlosesten davon.

[Sven Hartge]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
> Friedemann Stoyan <use...@ip6-mail.de> wrote:

>> Normales Browsing, gefühlt 90% SSL geht nicht in den Cache. Debian
>> Pakete aber

> Nach Zahlen von Google 68% des Chrome-Traffics unter Android und
> Windows und über 78% des Chrome-Traffics unter Chrome-OS und Mac.

Auch vor SSL war Web-Caching tot, weil viele der Inhalte dynamisch sind
und schon vom Server als "nicht cachebar" markiert waren.

Als ich in 2010 den transparenten Zwangs-Proxy $hier an der Hochschule
abgeschaltet habe, lag die Cache-Hit-Rate bei unter 2%. Und das war nur
für den HTTP-Traffic, HTTPS hat der Cache ja gar nicht erst gesehen!

Dieser Werte dürfte heute noch schlechter geworden sein.

Es lohnt sich heute einfach nicht mehr, irgendwelche Beschleunigungen
durch eine Proxy-Cache erwarten zu wollen und dort Zeit und Arbeit zu
investieren.

Dinge wie z.B. Paket-Caches für Debian/Ubuntu erledigt man besser mit
spezialisierter Sofware, wie apt-cacher-ng o.ä..

S°

--
Sigmentation fault. Core dumped.

[Ralph Aichinger]

Holger Marzen <hol...@marzen.de> wrote:
> Also SSL überall. Ja, da gibt es ein ausgeprägtes Sendungsbewusstsein,
> wenn man sieht, wie Du Dich dafür ins Zeug legst und Kritik auf der
> persönlichen Ebene angehst.

Ja, SSL überall. Welchen Nachteil hat es?

> Können vor Lachen auf anderer Leute Browser. Dazu kommen Blockierungen
> als Standardeinstellung in „Sicherheitslösungen“.

Einfach weil typischerweise selbstsignierte Zertifikate nur
dann Sinn ergeben, wenn man seinem Gegenüber einen Fingerprint
geben kann. Out of band. Wenn man das kann, dann kann man auch
gleich andere Dinge einstellen.

> Firmen begründen das Blocken von Seiten mit selbstsigniertem Zertifikat
> mit angeblichen Sicherheitsgründen.

Ich habe noch nie eine Firma gesehen, die selbstsignierte Zertifikate
blockt, im Sinne von Zugriff darauf sperrt.

> Da SSL-Verbindungen gewohnheitsmäßig
> aufgebrochen werden, können diese Verbindungen aber genauso gescannt
> werden wie unveschlüsselte.

Ich glaube das mit dem "gewohnheitsmäßigen aufbrechen" von Verbindungen
durch Institutionen weit unterhalb von Geheimdiensten (da halte ich das
für durchaus real vorstellbar) läuft auch langsam aus. In Zeiten von
BYOD schafft es kaum ein Unternehmen mehr das transparent (d.h. so,
daß die Mitarbeiter das nicht mitkriegen) zu machen.

> Die Begründung ist daher ein Vorwand. Es
> geht darum, selbstsignierte Zertifikate auszumerzen.

Nein. Selbstsignierte Zertifikate können in dem Bereich in dem sie
Sinn ergeben natürlich weiterhin verwendet werden. Dort, wo man
"Laien" selbstsignierte Zertifikate am Client zumutet, ohne
Einschulung und Betreuung, da werden sie zu recht ausgemerzt, denn
sie sind dort nur Sicherheitstheater (ohne Gegenlesen des Fingerprints).

> Gründe dafür mag es
> viele geben. Aber keiner hat was mit Sicherheit zu tun.

Ich halte das für eine Verschwörungstheorie. Niemand will
selbstsignierte Zertifikate ganz ausmerzen.

> Abgesehen davon, dass Zeugen Jehovas überzeugt sind, das moralisch
> Richtige zu tun, stehen hinter der SSL-Missionierung deutlich niederere
> Beweggründe. Rechthaberei und mangelnde Weitsicht sind noch die
> harmlosesten davon.

"SSL-Missionierung" kann natürlich nur einen kleinen Teil der
Sicherheitsprobleme im Web lösen. Sie hat aber immerhin *keine
nennenswerten Nachteile* gegenüber unverschlüsselter Übertragung.
Daher finde ich sie prinzipell begrüßenswert.

Jenseits ob man sie will oder nicht, sie ist nicht mehr aufzuhalten.

[Holger Marzen]

* On Sun, 17 Jun 2018 12:31:28 +0200 (CEST), Ralph Aichinger wrote:

> Holger Marzen <hol...@marzen.de> wrote:
>> Also SSL überall. Ja, da gibt es ein ausgeprägtes Sendungsbewusstsein,
>> wenn man sieht, wie Du Dich dafür ins Zeug legst und Kritik auf der
>> persönlichen Ebene angehst.
>
> Ja, SSL überall. Welchen Nachteil hat es?

Nichtanzeige der Seite, weil der Betreiber noch nicht übers Stöckchen
gesprungen ist und noch den neulich aus den Browsern entfernten
Hash-Algorithmus verwendet. Derzeit sind das einige Behördenseiten.
Ideologie ist, wenn die Rückwärtskompatibilität kaputtgemacht wird,
statt eine wegklickbare Warnung anzuzeigen, und der Seitenbetreiber die
Schuld haben soll.

>> Firmen begründen das Blocken von Seiten mit selbstsigniertem Zertifikat
>> mit angeblichen Sicherheitsgründen.
>
> Ich habe noch nie eine Firma gesehen, die selbstsignierte Zertifikate
> blockt, im Sinne von Zugriff darauf sperrt.

Ich schon.

>> Da SSL-Verbindungen gewohnheitsmäßig
>> aufgebrochen werden, können diese Verbindungen aber genauso gescannt
>> werden wie unveschlüsselte.
>
> Ich glaube das mit dem "gewohnheitsmäßigen aufbrechen" von Verbindungen
> durch Institutionen weit unterhalb von Geheimdiensten (da halte ich das
> für durchaus real vorstellbar) läuft auch langsam aus. In Zeiten von
> BYOD schafft es kaum ein Unternehmen mehr das transparent (d.h. so,
> daß die Mitarbeiter das nicht mitkriegen) zu machen.

Ich sehe nicht, dass das ausläuft.

>> Die Begründung ist daher ein Vorwand. Es
>> geht darum, selbstsignierte Zertifikate auszumerzen.
>
> Nein. Selbstsignierte Zertifikate können in dem Bereich in dem sie
> Sinn ergeben natürlich weiterhin verwendet werden. Dort, wo man
> "Laien" selbstsignierte Zertifikate am Client zumutet, ohne
> Einschulung und Betreuung, da werden sie zu recht ausgemerzt, denn
> sie sind dort nur Sicherheitstheater (ohne Gegenlesen des Fingerprints).

Und das rechtfertigt, die Seiten zu sperren? Sehe ich anders.

>> Gründe dafür mag es
>> viele geben. Aber keiner hat was mit Sicherheit zu tun.
>
> Ich halte das für eine Verschwörungstheorie. Niemand will
> selbstsignierte Zertifikate ganz ausmerzen.

Heute ist es noch eine Verschwörungstheorie, morgen reibt sich
vielleicht so mancher die Augen. Mal sehen, wie lange es dauert, bis
sich Google traut, http komplett aus Chrome auszubauen. Vielleicht wird
der erste Versuch ja nur ein „bedauerlicher Fehler“ sein.

[SSL-Verschlüsselung für Webseiten]

> Jenseits ob man sie will oder nicht, sie ist nicht mehr aufzuhalten.

So wenig wie Virenscanner, in der Tat.

[Tim Ritberg]

Am 17.06.2018 um 12:29 schrieb Sven Hartge:
und Mac.
>
> Auch vor SSL war Web-Caching tot, weil viele der Inhalte dynamisch sind
> und schon vom Server als "nicht cachebar" markiert waren.

Das gilt aber doch größtenteils nur für Webseiten. Bilder lassen sind
gut cachen. Vorallem sind das die größten Brocken.

Tim

[Kay Martinen]

Am 17.06.2018 um 12:07 schrieb Ralph Aichinger:

> Holger Marzen <hol...@marzen.de> wrote:
>
>> - Selbstsignierte Zertifikate werden systematisch diskreditiert und von
>> den üblichen MITM-Geräten vieler Firmen und Institutionen als unsicher
>> blockiert – selbst wenn SSL-Verbindungen aufgebrochen werden
>

> Warum das alles irgendwas mit dem Aufbrechen von Verbindungen zu tun
> haben sollte ist mir nicht klar. LE macht das aufbrechen eher
> schwieriger als leichter, verglichen mit selbstsigniertem.

Eine Frage. Wenn es so einfach wäre wie es hier schiene(=machen viele),
wieso kann Squid dann nicht auch SSL-Verbindungen aufbrechen - und damit
solche Inhalte weiterhin Cachen. Ich meine, auch Firefox hat eine eigene
Proxy-einstellung für SSL-Verbindungen. Geht das etwa nur mit einem
Zertifikat, und welchem dann bitte?

> Nein. LE ist für Cronjobs gedacht.

Häh? Was hat Let's Encrypt denn mit Cronjobs zu schaffen? Ich sehe da
keinen Zusammenhang.

[Kay Martinen]

Ich hab eben mal in einem Banalen Browsergame nach gesehen. Die Bilder
dort kommen AUCH alle über https. So wie die gameseite selbst auch -
seit ein paar Wochen.

Früher war das normales http und als ich noch ipfire mit proxy laufen
hatte habe ich einen merkbaren Geschwindigkeitssprung gesehen wenn die
Seite ein zweites mal geladen wird (variiert eh nur in wenigen
Elementen, der rest war dann im cache). Ist zwar kein Echtzeitspiel aber
ohne das muß alles immer wieder über eine lahme 2Mbit Leitung und das
nervt auf Dauer.

[Paul Muster]

LE ohne Automatisierung funktioniert praktisch nicht. Und
Automatisierung macht man bei den Betriebssystemen, die hier OnT sind,
i.A. mit cron.


mfG Paul

[Holger Marzen]

* On Sun, 17 Jun 2018 13:46:45 +0200, Kay Martinen wrote:

> Am 17.06.2018 um 13:31 schrieb Tim Ritberg:
>> Am 17.06.2018 um 12:29 schrieb Sven Hartge:
>> und Mac.
>>>
>>> Auch vor SSL war Web-Caching tot, weil viele der Inhalte dynamisch sind
>>> und schon vom Server als "nicht cachebar" markiert waren.
>> Das gilt aber doch größtenteils nur für Webseiten. Bilder lassen sind
>> gut cachen. Vorallem sind das die größten Brocken.
>
> Ich hab eben mal in einem Banalen Browsergame nach gesehen. Die Bilder
> dort kommen AUCH alle über https. So wie die gameseite selbst auch -
> seit ein paar Wochen.

Weschens der Sischerheit! Nun gut, meine Ansicht zu SSL überall ohne
Sinn und Verstand ist bekannt.

[Holger Marzen]

* On Sun, 17 Jun 2018 13:35:44 +0200, Kay Martinen wrote:

> Am 17.06.2018 um 12:07 schrieb Ralph Aichinger:
>> Holger Marzen <hol...@marzen.de> wrote:
>>
>>> - Selbstsignierte Zertifikate werden systematisch diskreditiert und von
>>> den üblichen MITM-Geräten vieler Firmen und Institutionen als unsicher
>>> blockiert – selbst wenn SSL-Verbindungen aufgebrochen werden
>>
>> Warum das alles irgendwas mit dem Aufbrechen von Verbindungen zu tun
>> haben sollte ist mir nicht klar. LE macht das aufbrechen eher
>> schwieriger als leichter, verglichen mit selbstsigniertem.
>
> Eine Frage. Wenn es so einfach wäre wie es hier schiene(=machen viele),
> wieso kann Squid dann nicht auch SSL-Verbindungen aufbrechen - und damit
> solche Inhalte weiterhin Cachen. Ich meine, auch Firefox hat eine eigene
> Proxy-einstellung für SSL-Verbindungen. Geht das etwa nur mit einem
> Zertifikat, und welchem dann bitte?

Das geht nur, wenn Du die Endgeräte kontrollierst, also z.B. in Firmen.
Die MITM-Box (z.B. von Bluecoat) spielt dann SSL-Server mit einem
Zertifikat, das sie on-the-fly ausstellt. Das entsprechende
CA-Zertifikat ist in den Browsern der Mitarbeiter hinterlegt.

>> Nein. LE ist für Cronjobs gedacht.
>
> Häh? Was hat Let's Encrypt denn mit Cronjobs zu schaffen? Ich sehe da
> keinen Zusammenhang.

Es gibt Leute, die halten es für unglaublich hip und sicher, dass
Serverbetreiber SSL-Zertifikate einsetzen, die nur wenige Monate gültig
sind, die aber automatisiert (per Cronjob) erneuert werden.

[Sven Hartge]

Interessanterweise sind/waren auch eigentlich statische Daten mit den
entsprechenden Cache-Control-Header als uncachebare markiert.

Die Weisheit dieses Entschlusses seitens der
Webdesigner/Server-Betreiber hat sich mir schon damals nicht wirklich
erschlossen.

[Tim Ritberg]

Am 17.06.2018 um 15:29 schrieb Sven Hartge:

> Interessanterweise sind/waren auch eigentlich statische Daten mit den
> entsprechenden Cache-Control-Header als uncachebare markiert.

Das kann man Squid ignorieren lassen :-D

Tim

[Sven Hartge]

Ja, kann man.

Führt zu "interessanten" Problemen. (Frag nicht, warum ich dass weiß.)

[Ralph Aichinger]

Tim Ritberg <t...@server.invalid> wrote:
> Das gilt aber doch größtenteils nur für Webseiten. Bilder lassen sind
> gut cachen. Vorallem sind das die größten Brocken.

Eher nicht (mehr). Stichwort "mixed content".

https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content

[Ralph Aichinger]

Sven Hartge <sh-...@svenhartge.de> wrote:
> Die Weisheit dieses Entschlusses seitens der
> Webdesigner/Server-Betreiber hat sich mir schon damals nicht wirklich
> erschlossen.

Wenn du schon mal Webentwickler kurz vor dem Beten[1]
auf ihre Reload-Knöpfe einhämmern hast sehen, daß
ja rechtzeitig vor der Präsentation vor $WICHTIGE_MANAGER
alle DNS-TTLs ausgetimed, alle gecacheten Sachen
verschwunden u.ä. sind, dann weißt du warum.

/ralph -- Änderungswünsche kommen prinzipiell in Zeiträumen
die kürzer sind als jede eingestgellte TTL

[1] oder anderen religiösen Anwandlungen

[Ralph Aichinger]

Kay Martinen <k...@martinen.de> wrote:
> Eine Frage. Wenn es so einfach wäre wie es hier schiene(=machen viele),
> wieso kann Squid dann nicht auch SSL-Verbindungen aufbrechen - und damit
> solche Inhalte weiterhin Cachen. Ich meine, auch Firefox hat eine eigene
> Proxy-einstellung für SSL-Verbindungen. Geht das etwa nur mit einem
> Zertifikat, und welchem dann bitte?

Das geht nur wenn man dem Client ein Zertifikat unterschieben kann.
D.h. entweder man bei einem Geheimdienst ist (oder vergleichbares),
oder bei einem Unternehmen die Client-Infrastruktur vollständig
kontrolliert. Und selbst da wird es technisch kompetenten Leuten
auffallen, u.U.

> Häh? Was hat Let's Encrypt denn mit Cronjobs zu schaffen? Ich sehe da
> keinen Zusammenhang.

Let's Encrypt-Zertifikate werden für 3 Monate ausgestellt, und die
Software dafür ist darauf vorbereitet, daß man sie regelmäßig z.B.
einmal die Woche laufen läßt. Wenn das Zertifikat kurz vor der
Erneuerung ist, so wird es automatisch erneuert. Wenn nicht, dann
auch kein Problem.

Ja, man muß einen Cronjob machen. Nein, sonst hat es keine Nachteile,
und es ist auch kostenlos. Ich habe außer hier in der NG noch
niemanden getroffen, der daraus eine Verschwörungstheorie spinnen
würde. Es ist ja nicht so, daß Cronjobs weh tun würden oder teuer
wären. Und manuelles Erneuern geht natürlich immer noch. Man kriegt
sogar eine Warnmail vor dem Ablaufen.

[Tim Ritberg]

Am 17.06.2018 um 20:10 schrieb Sven Hartge:

>
> Ja, kann man.
>
> Führt zu "interessanten" Problemen. (Frag nicht, warum ich dass weiß.)

Kann ich mir bei Bilder nicht vorstellen, eher bei CSS und JS.

Tim

[Tim Ritberg]

Am 17.06.2018 um 20:12 schrieb Ralph Aichinger:
> Tim Ritberg <t...@server.invalid> wrote:
>> Das gilt aber doch größtenteils nur für Webseiten. Bilder lassen sind
>> gut cachen. Vorallem sind das die größten Brocken.
>
> Eher nicht (mehr). Stichwort "mixed content".
>

Ich redete von dynamischen Sites ohne SSL.

Tim