Jedes Jahr bringe ich mal einen Artikel über das technische Rahmenwerk, in dem dieser Blog existiert. Da hat sich im letzten Jahr einiges verändert.

Willkommen auf dem 693. Beitrag dieses Blogs

32 Kartenpfade, 693 Beiträge, 1.703 Bilder und 3.523 gesetzte Text-Links –
das ist es von meiner Seite aus. Und dann gibt es ja noch die andere Seite – Deine.

Und wo ich grade die Domain für mein PIWIK umgestellt habe, kann ich auch gleich die Tracking-Ergebnisse veröffentlichen:
Bitte schön:
hier der anonyme Zugang zu den anonym erhobenen Daten.

Aber nun der Blick auf die erweiterten Einstellungen der Seite:

Protokoll:
HTTPS

Das S im Protokollnamen steht für “secure”. Das heißt, dass diese Seite nur aufgerufen werden kann, wenn eine verschlüsselte Verbindung zwischen Deinem Browser und dem Server, auf dem meine Inhalte liegen, besteht. Davon bekommst Du nichts mit. Andere allerdings auch nicht. Der Austausch der Daten ist für Otto-Normal-ich-steck-mal-meinen-Finger-ins-offene-WLAN nicht mehr im Klartext lesbar und das seit dem 28.12.2016.

Header:
HSTS

Jetzt wird es allmählich paranoid, aber nur ein bisschen, denn die Krönung mit dem Fallback-Serverzertifikat habe ich dann doch nicht gemacht. Wird die Website das erste Mal aufgerufen, vertraut der Browser dem ausgelieferten Zertifikat. DEM Zertifikat, sollte es ein anderes zwar gültiges, aber dennoch nicht das Gleiche handeln, verweigert der Browser die Anzeige. Mit im ersten Besuch aktiviertem HSTS verweigert er sowieso den Aufruf der Seite mit HTTP – nur noch Verbindungen mit HTTPS und dem erstmalig ausgelieferten Zertifikat sind gültig. Es sind halt schon CA geknackt worden – und mit einem im Vorhinein definierten Fallback-Zertifikat müssten dann zwei CA gebrochen werden um andere Inhalte, als ich sie auf der Seite platziert habe, anzeigen zu lassen ohne meinen Server gebrochen zu haben.

Content:

Content-Security-Policy

child-src https://www.yumpu.com https://*.westrad.de; connect-src ‘self’ https://*.westrad.de; default-src ‘self’; font-src https://fonts.gstatic.com https://*.westrad.de data:; img-src https://*.westrad.de https://*.openstreetmap.org/ data:; media-src https://*.westrad.de; object-src ‘none’; script-src https://*.westrad.de ‘unsafe-inline’ ‘unsafe-eval’ https://cdn.polyfill.io; style-src ‘unsafe-inline’ https://*.westrad.de https://fonts.googleapis.com; base-uri ; form-action ‘self’; block-all-mixed-content 1; upgrade-insecure-requests 1;

Wow, hier kann ich den Browsern über den HTTP-Kopfzeilen mitteilen, welche Inhalte überhaupt angezeigt werden dürfen. Ob nicht doch über einen wie auch immer gearteten Angriff auf die WordPress-Skripte nicht doch malicious Code auf den Weg zum Client gebracht wird. Immerhin würde der dann nicht mehr ausgeführt werden dürfen, oder die im Schadcode definierten Quellen zum Nachladen von noch mehr Schadcode wären geblockt. Also muss der Angriff ausgefeilter sein, als einfach nur die Ausnützung einer Sicherheitslücke auf Skript-Ebene. Es bleibt ein Ratten-Rennen – die Hürden können nur höher gelegt werden, unüberwindbar sind sie nicht.

Subdomains:

cookieless	static.westrad.de
tracking	piwik.westrad.de
content	blog.westrad.de

Das ist jetzt mehr oder weniger der Performance geschuldet, die drei Subdomains zeigen auf unterschiedliche Bereiche eines Hosts. Bei jeder Anfrage an den Server wird vom Browser der Inhalt des auf dem Client-Rechner hinterlegten Cookie mit übermittelt. Da es bei den Bildern aber fürchterlich egal ist, ob da jetzt ein Cookie mitgeschickt wird, oder nicht, kann ich das auch weglassen. Die Subdomain ist über eine Server-Anweisungs-Datei (.htaccess) so konfiguriert, dass keine Cookies gesetzt werden, folglich sind die Aufrufe vom Client an den Server schlanker. Das läppert sich.
Auf jeden Fall einen Cookie möchte ich aber beim Tracking gesetzt haben.
Da ich den unterschiedlichen Systemen WordPress und PIWIK nur von hier | bis | da traue, habe ich ihnen unterschiedliche Datenbanken und Verzeichnisse zugewiesen. Eine Kompromittierung des einen bedingt keine Kompromittierung des anderen.
Der Contentbereich blog.westrad.de braucht allerdings auch ein Cookie, sonst könnte ich nur schwer Inhalte auf der Backend-Oberfläche einstellen und bearbeiten.

Reputation:

Tja, die Gefährdungslage im Internet ist komplex, die Angriffsvektoren vielfältig – aber es geht ja grade um “solide paranoide”. Es können ja auch ganz andere Angriffe auf einen Blog gefahren werden. Wenn ich jemandem schaden möchte, dann ist mir jedes Mittel recht. Zum Beispiel könnte ich gefakete Internetseiten aufbauen, oder Facebook-Profile oder oder oder, mit denen ich das Ansehen in den Dreck ziehe. Fotomontagen, Texte, die knapp daneben sind, bizarre Statements – mir fiele eine Menge ein. Weil ich weiß was geht, habe ich jetzt mir einen Account von keybase.io zugelegt. Wer dem Twitter-Account vertraut, vertraut auch der Website und verse-visa – welcher Account da nicht mit aufgeführt wird, hinter dem stehe ich auch nicht.
Dementsprechend: – es gibt keinen facebook-Account, der von mir bespielt wird – es wird auch nie einen geben. Der zum Blog gehörige Twitter-Account wird über diese Plattform mithilfe von Kryptografie-Algorithmen verifiziert.

Folgende Grundsätze verfolge ich immer noch:

Rein subjektive Artikel, eigene Bilder, das Thema hat immer einen Bezug zu meiner Mobilität mit dem Fahrrad, oder zu Pedelecs im Allgemeinen –
Keine Werbung, transparentes Tracking, möglichst wenig externe Dienste (… eigentlich nur OpenStreetMap).

Ah ja, flattr ist wieder neu aufgesetzt, so häufig tauchen Bilder von mir nicht in Schulbüchern auf. Bei Paypal kann mir auch direkt eine Gratifikation hinterlassen werden, allerdings habe ich den nach-Hause-telefonierenden-Button nicht eingebunden. Paypal? Solide paranoide? Ähm – noch eine zu fütternde Datenkrake.