Diskussion:IT/Dokumentation/Webcache

Wie funktioniert das mit https?

Wie läuft das eigentlich, wenn jemand auf https://www.piratenpartei.de zugreifen will, und vom DNS-Server einen der Reverse-Proxies genannt bekommt? Gibt es da irgend einen 'Hint', den der DNS-Server mitschickt oder so? --Patrick Nagel 10:52, 24. Sep. 2009 (CEST)

Nein - der Server (hier: jeder einzelne Squid) muss "nur" ein gültiges Zertifikat besitzen, in dem steht, dass er www.piratenpartei sei. Votan 10:37, 24. Sep. 2009 (CEST)

Aber es steht nirgendwo was davon in der angegebenen Konfigurationsdatei, soweit ich das sehe. Und es steht auch nirgends dass / wie man sich so ein Zertifikat erstellt (eines das auch nicht gleich wilde Fehlermeldungen im Browser des Benutzers hervorruft). --Patrick Nagel 10:52, 24. Sep. 2009 (CEST)

Der HTTPS-Teil kann z.B. über einen STUNNEL realisiert werden. Ein Zertifikat kann man zwar selber erstellen, aber das muss (um nicht einen Browserfehler zu erzeugen) von einer bekannten CA signiert werden. Das kostet Geld, und die Zertifizierungsstellen sollten auch prüfen, dass Dir die Domain auch gehört. Und das wird nicht ganz einfach, da Du nicht der Owner von Piratenpartei.de bist. Die Hauptidee bei den Caches war, dass Otto-Normaluser bei hoher Last noch eine Piratenseite abrufen können - und das ist üblicherweise HTTP-ohne-S Votan 11:26, 24. Sep. 2009 (CEST)

Aber wie kann das funktionieren solange nicht ALLE Reverse-Proxies so ein Zertifikat haben? Andernfalls bekommt jeder https-User der vom DNS die IP eines Reverse-Proxy ohne passendes Zert. zurückbekommt eine Fehlermeldung. Außerdem ist https, wie gesagt, in der angegebenen Config gar nicht berücksichtigt. Folglich hören die so konfigurierten Proxies gar nicht auf Port 443, und https-User stoßen einfach auf einen geschlossenen Port. Oder?

Zurzeit wird der Port 443 via Port Weiterleitung und NAT an die Piraten Kisten durchgereicht.

Ok, wäre ideal wenn das auch auf der Seite erwähnt und würde, evtl. mit iptables-Kommandos um sowas einzurichten. --Patrick Nagel 13:56, 24. Sep. 2009 (CEST)

Ich habe das jetzt mal auf meinem Server umgesetzt. Ein Zugriff auf https://piraten.bucuo.de sollte jetzt via IP-Forwarding auf https://94.23.165.40 landen. Wenn das nun jeder Reverse-Proxy-Betreiber so einrichtet, sollte alles passen. Falls das nicht bei allen eingerichtet ist, gehen https-Zugriffe nach dem Zufallsprinzip (Round Robin) ins Leere! Ich werde deshalb eine Spalte 'https' in die Liste einbauen, in der vermerkt wird, ob https bei einem Server geht. Nur Server bei denen https geforwardet wird, sollten auch in den DNS aufgenommen werden. --Patrick Nagel 16:05, 25. Sep. 2009 (CEST)

Status (2009-09-24)?

Wie weit ist dieses Projekt eigentlich fortgeschritten? Ich war irgendwie davon ausgegangen, dass die Reverse-Proxies unter vorhandene Reverse-Proxies schon produktiv wären (mit Ausnahme des von mir heute hinzugefügten). Aber nach obiger https-Unterhaltung kommen mir da nun Zweifel.

Gibts einen Plan? Wie kann ich helfen? --Patrick Nagel 14:02, 24. Sep. 2009 (CEST)

Frage Squid: CONNECT safe?

Ohne das jetzt weiter erforscht zu haben, wieso wird CONNECT als zugelassene Methode im squid sample angegeben? Ist das dann auf die backendip als Ziel beschränkt? --eckes

CONNECT und Port 443 waren noch 'drin, weil das Sample ursprünglich nicht Host:-gebunden war, sondern blind durchroutete. Da SSL verschlüsselt ist und nicht nach Host:-Header verzweigen kann, geht das in der akuten Beschreibung nicht und ist so Käse. Mit den "http_access deny !piraten" ACL sollte das nicht missbrauchbar sein. Ich habe das Beispiel jetzt mal korrigiert. Votan 14:21, 24. Mai 2012 (CEST)

Der Unterschied web/www

Ich meine mich zu erinnern dass bei der BTW die Unterscheidung nach www.piratenpartei.de (RR der reverse proxies) und web.piratenpartei.de (backend direkt) gemacht wurde. Ist das noch aktuell, oder geplant das wieder zu tun? Die Beispielconfigs haben feste IPs drin, das ist ja auch problematisch. (Und Webmaster und Bots wollen vermutlich auch nen offiziellen Weg am Cache vorbei haben). --eckes

Das war damals ein Schnellschuss, da die BTW drohte, aber es drohte, nichts lastfestes zur Verfügung zu haben. Und mit der Erfahrungen der Europawahl im Nacken ist das dann schnell umzugsfertig zusammengebastelt worden. Effektiv sind dann nur einige wenige von den Community-Squids auch in den DNS-RR aufgenommen worden. Die Basisinfo wie so etwas geht sollten wir hier aber vorhalten (ebenso wie das Spiegel-Skript), um auf Varianten vorbereitet zu sein, falls das mal nötig wird. Votan 14:30, 24. Mai 2012 (CEST)