Kreuvfs Allerweltsblog

2016-04-20

HTTPS: Blog mit sicherer Verbindung

Abgelegt unter In eigener Sache,Software von Kreuvf um 11:42:15

Seit gestern ist dieser Blog nicht mehr nur via HTTP, sondern auch via HTTPS zu erreichen. Dadurch wird die Kommunikation vom Benutzer zum Server und umgekehrt verschlüsselt, sodass das routinemäßige Abhören von Verbindungen durch die Bösen deutlich erschwert bis unmöglich gemacht wird.

Umstellungsprobleme

Auch die Feeds sind jetzt via HTTPS zu erreichen, was aber bedeutet, dass ihr die URL des Feeds in eurem Feedreader ändern müsst. Dadurch werdet ihr zwangsläufig doppelte Einträge erhalten, zumindest war das meine Beobachtung in Thunderbird.

Da dieser Blog wie so vieles historisch gewachsen ist, habe ich Links auf meine eigenen Seiten und Blogbeiträge im Blog immer mit der vollen URL angegeben. Da der Blog ab sofort aber unter zwei Protokollen erreicht werden kann, würde die explizite Angabe des Protokolls in den Links dazu führen, dass beim Folgen von Links auf meinen Seiten ihr ständig zwischen der ungesicherten und der gesicherten Variante wechseln würdet. Ich habe dazu sämtliche URLs in relative URLs umgewandelt, sodass die Angabe des Protokolls fehlt. WordPress ist nativ leider zu scheiße (oder ich zu dumm), um sämtliche von WordPress generierten Links ebenfalls ohne Protokoll generieren zu lassen, weshalb ich früher oder später davon wegkommen werde und mir ein auf meine Bedürfnisse zugeschnittenes CMS suchen/erstellen werde.

Skript zur Umstellung

Weil ich selbst keine Lust darauf hatte meine ganzen Artikel nach Verweisen auf meine Seite(n) zu durchsuchen und das Protokoll zu verändern, habe ich mich des Kommandozeilenprogramms „sed“ und regulärer Ausdrücke bedient. Dabei herausgekommen ist folgendes Snippet, das sämtliche Verweise in den Attributen „href“ und „src“ so verändert, dass das Protokoll entfernt wird:

sed -r -i \
-e "s_href=([\"'])?https?://([a-z0-9\.]*\.)?kreuvf\.de([^\"' ]*)\1_href=\1//\2kreuvf.de\3\1_g" \
-e "s_src=([\"'])?https?://([a-z0-9\.]*\.)?kreuvf\.de([^\"' ]*)\1_src=\1//\2kreuvf.de\3\1_g" \
datenbankdump.sql

Dieses Snippet stellt keinen vollwertigen HTML-Parser dar und wurde nur mit Bash und dem von mir erzeugten HTML getestet. Das heißt insbesondere, dass

  • kein Whitespace um das Gleichheitszeichen zwischen Attributname und Attributwert vorkommt,
  • der Attributwert ausnahmslos in doppelte Anführungszeichen gefasst ist ("), auch wenn das Snippet ebenso mit einem Apostroph (') klarkommen sollte,
  • das Protokoll immer angegeben ist und
  • Verweisziele keine Leerzeichen enthalten.

„sed“ wird durch den Schalter „-r“ in den Extended-Regex-Modus versetzt, überschreibt durch „-i“ die Eingabedatei und führt den hinter dem „-e“ befindlichen Befehl aus. Der Befehl „s“ steht für „Suchen & Ersetzen“, das Suchmuster befindet sich zwischen dem ersten und zweiten Unterstrich, die Ersetzung zwischen dem zweiten und dritten Unterstrich. Der Schalter „g“ am Ende des Befehls sorgt dafür, dass „sed“ alle Treffer einer Zeile sucht und ersetzt statt nur dem ersten. Die Backslashes am Ende der Zeile gestatten es den Befehl über mehrere Zeile zu schreiben. Falls jemand Hilfe beim Anpassen des Snippets braucht, meldet euch einfach per Mail.

Das Verfahren sieht wie folgt aus:

  1. Vollständiges Datenbank-Backup anlegen, zum Beispiel mit dem Plugin „WordPress Database Backup“
  2. Snippet auf eine Kopie des Datenbank-Backups anwenden
  3. Bearbeitetes Datenbank-Backup in eine Testdatenbank einspielen
  4. Testen, ob der Blog bei Verwendung der Testdatenbank noch funktioniert (Login, Protokollabhängigkeit der Links)
  5. Bearbeitetes Datenbank-Backup in die Live-Datenbank einspielen

Sollte ich auf bislang unentdeckte Probleme stoßen, werde ich den Artikel entsprechend aktualisieren.

Warum erst jetzt?

In meinem Tarif wäre früher schon die Option gewesen einen Verschlüsselungsproxy zu benutzen. Das empfand ich aber immer als sehr unschön, da sämtliche Links dann auch immer den Proxy drin gehabt hätten. Ich habe daher darauf gewartet, dass irgendwann mal echte Zertifikate für meine Domain(s) zu erschwinglichen Preisen ohne großen Aufwand möglich werden.

Dieser Zeitpunkt ist jetzt gekommen und die Umstellung ist nur möglich, weil mein Webhoster, all-inkl.com, die Nutzung von Zertifikaten von Let’s Encrypt vor nicht mal zwei Wochen ermöglicht hat. Zusätzlich dazu hat Let’s Encrypt letzte Woche Dienstag den Testbetrieb verlassen.

2016-04-05

Nicht noch mehr Blumen… oder doch?

Abgelegt unter Kurioses,Software,Technologie von Kreuvf um 11:42:19

Ich hatte ja bereits einmal mit einer Übersetzung aus dem Japanischen meine Freude an Google Translate. Was soll ich sagen? Google Translate hat wieder zugeschlagen:

Google Translate übersetzt „Er schenkte seiner Mutter nicht nochmal Blumen.“ mit „He gave his mother again flowers.“. Das ist im Englischen ein wenig holprig, aber noch viel schlimmer: die gegenteilige Aussage!

;_;

2016-03-12

AlphaGo-Zeitrechnung

Abgelegt unter Humor,Software,Technologie von Kreuvf um 21:53:53

Erwartungsgemäß haben Menschen es geschafft eine Maschine zu bauen, die besser in der Lage ist ein sehr komplexes Spiel zu spielen als einer der besten Menschen. In Anlehnung an ein auf asiatische Wunderkinder anspielendes Sprichwort habe ich dazu eine passende Grafik geschustert:
AlphaGo-Zeitrechnung: bis Jahr 0 AlphaGo: "Egal wie gut du in etwas bist, es gibt immer ein asiatisches Kind, das besser ist als du."; ab Jahr 0 AlphaGo: "Egal wie gut du in etwas bist, es gibt immer eine künstliche In-telligenz, die besser ist als du."

2015-11-25

Git-Syndrom

Abgelegt unter Humor,In eigener Sache,Software,Technologie von Kreuvf um 21:54:22

Wenn der Großteil, der Befehle, die man auf der Kommandozeile eintippt, irgendwas mit Git zu tun hat, kommt man irgendwann an den Punkt, dass jeder Befehl – ob Git oder nicht – mit einem „git“ davor auszuführen versucht wird:

$ git make xfour
git: 'make' is not a git command. See 'git --help'.

Did you mean one of these?
	blame
	merge
	stage

Diagnose: Git-Syndrom!

2015-09-19

GnuPG: Empfänger verstecken

Abgelegt unter Software von Kreuvf um 18:08:43

Gerade für Anfänger ist die Art und Weise wie asymmetrische Verschlüsselung funktioniert in der Regel schwer verständlich. Mein letzter Beitrag zum Thema GnuPG beschäftigte sich daher auch mit einer eher trivialen Frage: GnuPG und digitales Signieren.

Mit der Zeit habe ich aber immer mal wieder ein wenig mehr mit GnuPG zu tun gehabt und dabei einige sehr spannende Dinge gelernt. Eines davon möchte ich heute vorstellen, nämlich wie man eine gültige verschlüsselte Nachricht schreibt, die aber nicht von sich aus weiß, mit welchem Schlüssel man sie entschlüsseln kann.

Eine GnuPG-Nachricht besteht nicht nur aus der verschlüsselten Botschaft, sondern ist deutlich komplexer aufgebaut: zum einen kann der zu verschlüssende Text komprimiert werden, was das Phänomen erklärt, dass eine verschlüsselte Botschaft kleiner ist als der Klartext. Die Nachricht wird auch nicht wirklich mit dem öffentlichen Schlüssel des Empfängers verschlüsselt, sondern mit einem sogenannten „Session Key“, zu Deutsch: Sitzungsschlüssel. Dieser wird benutzt, um mittels eines symmetrischen Verfahrens die Nachricht zu verschlüsseln. Der Sitzungsschlüssel wird dann mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und gespeichert. Das hat den Vorteil, dass bei Nachrichten, die an mehrere Empfänger gehen sollen, der gesamte Klartext nur einmal verschlüsselt werden muss und nur die vergleichsweise geringe Informationsmenge, die der Sitzungsschlüssel darstellt, für alle Empfänger mit deren öffentlichen Schlüssel verschlüsselt werden muss. Damit der Empfänger die Nachricht möglichst schnell entschlüsseln kann, enthält sie daher auch einen Hinweis auf den für die Entschlüsselung notwendigen Schlüssel.

Will man allerdings möglichst anonym kommunizieren, das heißt so kommunizieren, dass ein Beobachter, der die Nachricht mitschneidet, nicht weiß, an wen die Nachricht gerichtet ist, darf kein Hinweis auf den Empfänger vorhanden sein. Dies lässt sich bewerkstelligen, indem man den Hinweis auf den für die Entschlüsselung notwendigen Schlüssel entfernt beziehungsweise erst gar nicht speichert. Beim Empfänger führt dies dazu, dass er jeden einzelnen seiner geheimen Schlüssel ausprobieren muss, in der Hoffnung, dass einer davon passt.

Dies lässt sich von der Kommandozeile aus wie folgt bewerkstelligen:
$ gpg --armor -R 'Anonymer Empfänger <anonymous@example.com>' --encrypt blogsnippet.txt

Wichtig ist hierbei, dass keine Signatur erzeugt wird, also „–sign“ fehlt, da sonst durch Mitschneiden der Nachricht bekannt wäre, wer der Absender ist. Der dazugehörige Abschnitt aus der man page:

       --hidden-recipient name

       -R     Encrypt for user ID name, but hide  the  key
              ID  of this user's key. This option helps to
              hide the receiver of the message  and  is  a
              limited countermeasure against traffic anal‐
              ysis. If this option or --recipient  is  not
              specified, GnuPG asks for the user ID unless
              --default-recipient is given.

Eine solche Nachricht (blogsnippet.txt.asc) sieht dann wie folgt aus:

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1

hQIMAwAAAAAAAAAAAQ//WPw1Am9ys+7n9cLM9epfadAqnl4bxEwTOs5cqRoEYR1s
xvAxCXzW937tN8/IIBBt5t2ua4RSU0on+8tGD2mQaoN+UZeKcSadAy9LM4zMpAUk
bSYHCpJvEM7o7eJ4Hupr9TO25VUU1kRTlvLapPAXNGYJRJSpounvyyUA0YYlFfYF
B0M42lBZ24qecUB2smRJL3C3/G0AMxZvw7y5yWKYT8T60CdrRNPVoQz0XLPD3JkX
gv/IiQBBqvcheaMvjivMdmhh/q15nLOzwe+7qFzhS6EqA9Yrh1ke2ZJAdRw6EAO8
OWJ9nVRo53BjS8RIVDAJaE7ew+vYx7+xLhloEXNKPnmyeVifREVSlxcsYnWudEkD
WAbebrXpazwdBxpnnwLEDrfqoc2k3jO6En1C2cro6cqR8mbvNVphuSK5EwloVn38
hqEoQxK4cOzVEuQNSqYBJnKZBBFBHU7runf0e0P8q9MsjPI1DtHH4NgwlCNilEgd
iFN3G4YqDhetnnMgv1Bv9fPmatfADvRTt3vrQOVLuvJYsFDzbLpn+iBcZPDRhIlP
lmdsV6S0ejiO/mguFaYZj62tWn7cJpvTdPHbxwvy/EbXZTlrWwF0H2GMFeFmReiq
cYYzYjTZTm/12+HlKwcHjYnMgDQNTtYoWVcRx6SZHDRhZ1PrE8rAdhxaqqd3I/PS
wLsBu0v9Z6M/1/AsoFKGsH2GOQU+JE8r7tg9FyW8+hebq1eQxpM25eZaYyqc2OPq
K3MT7ama8fN8ifZ7ss3JuIRblrq9oQpBQR9OVDxY7UbleuWbQ8VXK/5fogQ25Sgj
FpN6CBK9Kul3O/EthlQh7KD/jzRToHrnHnetAiGfb24QG/cy9DWoYaxNblNuwJi5
8H3HqFAO/GQyA2XV8ArksyheqVyUrikoW+wWIPETQs0ssKt/dEv8WwNsJ8gPXOzq
6RSI4Svlop15RzetvDfT7l9xSQ23otcD07WNKm2+TZuY0Grp+4BMNZMpwoMQMGaD
LRzE6aIMQiofEMpiJqyXZxi7NO/N2oDXVIIauKEKorppk8Lc+LxutNORFqOzeNAb
laF1UEGDhuqQV8esW90JLmbmBpfEIURrFLKGs5OK2h12R/0E8m6mzwfFsTZ8/xN9
S/Efr9cLKTf/y81AX4qYmfvoLHJM6+/bG/j8sBndWGtIohhvH73G6rVAjDiq
=I9QO
-----END PGP MESSAGE-----

Der Versuch sie zu entschlüsseln, wenn der passende geheime Schlüssel fehlt, sieht wie folgt aus (IDs unkenntlich gemacht):
$ gpg --decrypt blogsnippet.txt.asc
gpg: anonymous recipient; trying secret key 00000000 ...
gpg: anonymous recipient; trying secret key 00000001 ...
gpg: anonymous recipient; trying secret key 00000002 ...
gpg: anonymous recipient; trying secret key 00000003 ...
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: secret key not available

Vielleicht hat da draußen ja jemand mehr Glück und kann die Nachricht da oben entschlüsseln ;)

Es versteht sich von selbst, dass diese Methode nicht geeignet ist, um in E-Mails benutzt zu werden. E-Mails enthalten Empfänger- und Absenderinformationen (und den Betreff) grundsätzlich unverschlüsselt, es macht also Verschlüsselung nur umständlicher und bringt keinen Sicherheitsgewinn. Wie auch in der man page angesprochen, ermöglicht dies nur eine eingeschränkte Verteidigung gegenüber Verkehrsanalysen. Bei niederfrequenter Kommunikation auf von vielen Nutzern besuchten Diensten dürfte dies allerdings für eine deutliche Erschwerung der Verkehrsanalyse sorgen.

« Vorherige SeiteNächste Seite »