world of cryptosteve

Punk, Nerd, Atheist, Skeptiker, Misanthrop, .....

in eigener Sache: neue Zertifikate und Wechsel zu Let's Encrypt

Ohne Kommentare

Das Jahr ist schon wieder rum und es wurde Zeit für neue SSL-Zertifikate. Während ich diese bisher immer unter eher großem Aufwand von Startcom geholt habe, besteht jetzt die Möglichkeit, diese über das noch relativ junge Projekt Let's Encrypt zu beziehen. Um das Rad nicht mehrfach neu zu erfinden, habe ich mir die notwendigen Infos zum Erstellen, Beziehen und Verwalten der Zertifikate von unterschiedlichen Seiten geholt, unter anderem von:


Damit sollten ab sofort neue Zertifikate ausgeliefert und in allen verwendeten Programmen ohne weitere Rückfrage akzeptiert werden. Der SSL-Test auf Qualys SSL Labs gibt mir nach wie vor ein gutes A+.

Wer Fehler bemerkt, darf sie mir dennoch gerne mitteilen ....

Geschrieben von cryptosteve | Kommentieren
Translate article to english

24.05.2016 um 18:16:39

Gegendemo zur Neonazi-Veranstaltung in Buchholz am 03.04.2016

Mit 2 Kommentaren

6 Jahre nach der letzten Demonstration planen Neonazis erneut eine Veranstaltung in Buchholz.

Unter dem Deckmäntelchen einer harmlosen Bürgerbewegung mit dem Namen Bürgerbewegung Nordheide versucht man, in altbekanntem hetzerischen Jargon Stimmung zu machen. Wessen Geistes Kind die Autoren dort sind, erkennt man allerdings schnell anhand der Rhetorik, mit der die Beiträge dort geschrieben sind.

Auf meine Frage in einer geschlossenen Facebook-Gruppe hin, wer denn die Gegendemo organisiert und ob dazu überhaupt schon etwas bekannt ist, tauchte ein Screenshot davon öffentlich in der o.g. Bürgerwehr-Gruppe auf. Dort kannte man allerdings offenbar den Unterschied zwischen geschlossenen und geheimen Facebookgruppen nicht und entblödete sich auch nicht, dass auch noch mit breitem Grinsen zur Schau zu stellen.

Edit: Da der Facebook-Eintrag mittlerweile gelöscht ist, hier der Vollständigkeit halber noch ein Screenshot.

Die Antifa hat wie gewohnt schnell auf die angemeldete Veranstaltung reagiert und ihr Kommen aus verschiedenen Himmelsrichtungen angekündigt.

Mittlerweile hat die antifaschistische Einrichtung Heideruh eine Gegendemo angemeldet. Diesem Aufruf hat sich auch der Bürgermeister von Buchholz angeschlossen. Entsprechende Beiträge sind den nachfolgenden Publikationen zu entnehmen:


Ich kann die Aufrufe von Antifa, Heideruh, Stadt Buchholz und vielen mehr nur unterstützten und sage: Buchholz BLEIBT bunt ...

Den weiteren Verlauf könnt ihr auf Twitter unter den Hashtags #hh0304 und/oder #bu0304 verfolgen.

Kommt zahlreich, refugees welcome, no pasarán ...

Geschrieben von cryptosteve | Kommentieren
Translate article to english

31.03.2016 um 20:53:00

Abgelegt in Allgemeines, Politik

Kleine Tips für den Neueinstieg bei Archlinux

Ohne Kommentare

Nach längerer Zeit habe ich mich mal wieder mit Arch Linux versucht.

Dabei bin ich über einige kleine Hürden gestolpert, die zum Teil meiner Unwissenheit bzgl. der Arch-Namensgebung der Programme waren, zum Teil aber auch distributionsspezifisch zu sein scheinen. Dieser Blogbeitrag ist daher in erster Linie ein Reminder an mich selbst ... vielleicht profitiert ja der eine oder andere noch davon.

Here we go ...

Problem: Der NVidia-Treiber ist installiert, aber die 3D-Beschleunigung funktioniert nicht. Ein grep EE /var/log/Xorg.0.log enthält folgende Logzeilen:


[ 15.963] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
[ 15.963] (EE) NVIDIA(0): log file that the GLX module has been loaded in your X
[ 15.963] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If
[ 15.963] (EE) NVIDIA(0): you continue to encounter problems, Please try
[ 15.963] (EE) NVIDIA(0): reinstalling the NVIDIA driver.


Lösung: Installieren von nvidia-libgl - ggf. wird ein bereits installiertes mesa-libgl entfernt und durch das vorgenannte nvidia-libgl ersetzt.

Problem: Beim Versuch, einen pgp-key via pacman -r $key herunterzuladen, bricht der Keyimport mit folgender Meldung ab:


gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: IPC "connect" Aufruf fehlgeschlagen
gpg: Empfangen vom Schlüsselserver fehlgeschlagen: Kein Dirmngr


Lösung: das root das Verzeichnis ~/.gnupg erstellen und die Datei dirmngr_ldapservers.conf anlegen.


mkdir /root/.gnupg && touch dirmngr_ldapservers.conf

Quelle: https://bbs.archlinux.org/viewtopic.php?pid=1480388#p1480388

Problem: Ich finde unter Arch Linux keine /etc/rc.local (wie bei Debian), bzw. keine /etc/local.d/local.start wie bei Gentoo

Lösung: den Service für systemd selber schreiben (HOWTO in der nachfolgenden Quellenangabe)

Quelle: https://raymii.org/s/tutorials/rc.local_support_on_Arch_Linux_and_systemd.html

Das geschriebene systemd-service-file sollte meiner Meinung nach aber nicht in /usr/lib/systemd/system/rc-local.service liegen, sondern in /etc/systemd/system/rc-local.service und wird dann wie folgt hinzugefügt:


# systemctl enable rc-local.service
Created symlink from /etc/systemd/system/multi-user.target.wants/rc-local.service to /etc/systemd/system/rc-local.service.

Vor dem Start muss die Datei /etc/rc.local angelegt und ausführbar gemacht werden. Inhalt wie folgt:


#!/bin/sh
# enter stuff here
exit 0

Testweiser Start via systemctl start rc-local.service

Problem: Unter plasma5 sehen gtk2/gtk3-Anwendungen hässlich und deplatziert aus.

Lösung: community/gtk-theme-orion installieren und unter Systemeinstellungen -> Anwendungs-Stil -> GNOME Anwendungs-Stil (GTK) bei GTK2-Design/GTK3-Design aktivieren.

Problem: im Browser chromium sowie in firefox gibt es keinen Ton. Im syslog/journal steht ein Eintrag wie folgt:


Sep 06 10:04:51 sorum pulseaudio[7787]: [pulseaudio] module-udev-detect.c: You apparently ran out of inotify watches, probably because Tracker/Beagle took them all away. I wished people would do their homework first and fix inotify before using it for watching whole directory trees which is something the current inotify is certainly not useful for. Please make sure to drop the Tracker/Beagle guys a line complaining about their broken use of inotify.


Lösung: max_user_watches erhöhen, vgl. HOWTO in der Quellenangabe

Quelle: https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Outputs_by_PulseAudio_error_status_check_utilities

Geschrieben von cryptosteve | Kommentieren
Translate article to english

03.09.2015 um 20:15:00

Abgelegt in Linux

in eigener Sache: neue Zertifikate

Ohne Kommentare

Da StartSSL-class1-Zertifikate jeweils nur ein Jahr lang gültig sind, musste ich wieder in die Tiefen der Zertifikatserstellung hinab steigen und mir neue Zertifikate zusammen bauen. Diesesmal habe ich nicht auf die Schlüsselerstellung von StartSSL vertraut, sondern mir die Zertifikatsregistrierungsanforderung (CSR) selbst erstellt.

Da mir der SSL Labs Test jedoch in der Vergangenheit mehrfach mitgeteilt hat, ich würde noch das unsichere SHA1 verwenden, wollte ich es diesesmal richtig machen:

# openssl genrsa -out example.com.key 2028
# openssl req -new -key example.com.key -out example.com.csr -sha256


Das läuft schnell durch, kein Thema. Die csr-Datei wird dann bei StartSSL hochgeladen und nach Angabe weniger weiterer Daten bekommt man sein fertiges Zertifikat.

Auf dem Server wird das ganze dann mit dem Key zusammen an den lighttpd verfüttert und schon sollte der Server fortan eine komplette SHA2-Chain ausliefern.

Tut er aber nicht. Nach einigem Suchen bin ich dann drauf gekommen, dass auch das intermediate certificate auf SHA2 umgestellt werden muss. Das passende class1-sha2-intermediate muss dann wie folgt in lighttpd konfiguriert werden:

[ ... ]
ssl.ca-file = /path/to/ssls/sub.class1.server.sha2.ca.pem

Nachdem hier das alte SHA1-intermediate durch das neue SHA2-intermediate ersetzt war, hat es dann mit dem SSL-Test auch für ein A+ gereicht. (SSL Test für blog.crashmail.de)

Achja, und auf ein Problem bin ich noch gestoßen. Nach dem Aktivieren der neuer Zertifikate hat mir Firefox die Verbindung zum Server mit nachfolgender Meldung abgelehnt:
The OCSP server has no status for the certificate.

(Error code: sec_error_ocsp_unknown_cert)

Nach Durchlesen dieses Threads auf forum.startcom.org bin ich darauf gekommen, dass hier die neuen Zertifikate noch nicht bei der Zertifizierungsprüfungsstelle angekommen sind. Hier bleibt die Möglichkeit, einfach ein bißchen abzuwarten (bei mir hat es 15 Minuten gedauert, soll aber auch bis zu 6 Stunden dauern können), oder hilfsweise im Firefox OCSP auszuschalten (→ Einstellungen → Erweitert → Zertifikate → Validierung → [ ] Das Online-Zertifikatsstatus-Protokoll (OCSP) verwenden, um die aktuelle Gültigkeit von Zertifikaten zu bestätigen (← Haken entfernen)

Geschrieben von cryptosteve | Kommentieren
Translate article to english

29.05.2015 um 05:16:00

Abgelegt in in eigener Sache, Linux

in eigener Sache: Logjam-Angriffe

Ohne Kommentare

Kürzlich ist auf heise.de ein Artikel zur neuen Logjam-Attacke - Verschlüsselung von zehntausenden Servern gefährdet veröffentlicht worden. Ein Test mit dem im Artikel genannten Testtool ergab, dass auch blog.crashmail.de davon betroffen ist.

Ein Quertest über mein bevorzugtes Sicherheitstool auf SSL Labs bestätigte diese Annahme. Dort ist das Ranking meines Servers von A auf B abgerutscht.

Im Testtool auf weakdh.org sind auch die passenden Konfigurationsschnipsel für reihenweise Serverdienste hinterlegt, sodass der Fix ohne viel Aufwand möglich war.

Kurz und knapp: alles wieder gut

Geschrieben von cryptosteve | Kommentieren
Translate article to english

21.05.2015 um 05:04:00

Abgelegt in in eigener Sache

Gentoo Linux mit Verschlüsselung OHNE LVM

Ohne Kommentare

Seit vielen Jahren nutze ich bei Linuxinstallationen auf einer Workstation grundsätzlich eine Festplattenvollverschlüsselung (full disc encryption). Dazu nahm ich in der Vergangenheit eigentlich regelmäßig ein Setup mit LVM und LUKS. Der Logical Volume Manager (lvm) hatte unter anderem folgende zwei Vorteile:

  • Partitionsgrößen konnten nachträglich geändert werden
  • swap lag im LVM und war somit automatisch mit verschlüsselt
Als kleiner Nachteil kam mit dem LVM eine zusätzliche Abstraktionsschicht, die natürlich eine mögliche zusätzliche Fehlerquelle darstellt.

In heutigen Zeiten ist das nachträgliche Verändern der Partitionsgrößen in meinem Setup allerdings nicht mehr so wichtig. Das liegt nicht daran, dass ich überschwänglich viel Platz zur Verfügung habe, sondern - man glaubt es kaum - durch den Einsatz einer SSD eher zu wenig. So habe ich aktuell nur ca. 250GB auf meiner SSD zur Verfügung, sodass eine Aufteilung in mehrere Partionen (wie z.B. /usr, /home, /var, etc.) kaum mehr Sinn macht.

Da ich folglich alles auf einer Partition lasse, braucht es auch kein LVM mehr (Funktionen wie LVM-Snapshots habe ich in der Vergangenheit ohnehin nicht genutzt).

Welche Änderungen ergeben sich auf einem Gentoo-System also?

  • Bei der Installation braucht kein LVM mehr angelegt zu werden. Es kann unmittelbar mit der Einrichtung von LUKS begonnen werden. Ich verwende dazu cryptsetup -c aes-xts-plain64:sha512 -y -s 512 luksFormat /dev/sdaX.
  • Der Parameter "--lvm" ist beim Erstellen der initramfs via genkernel und der Eintrag dolvm in der grub.conf sind nicht mehr notwendig
  • Die Angabe von real_root=/dev/mapper/$cryptdevice in grub.conf ist nicht mehr erforderlich

Nachteil dieser Variante ist, dass swap nicht mehr automatisch im verschlüsselten Bereich liegt, was ein potentielles Sicherheitsrisiko darstellt. Wer aufgrund von Speicherknappheit also nicht gänzlich auf ein swap-Device verzichten möchte, legt es also entweder als swapfile mit im verschlüsselten Bereich an, oder aber er lässt das swap-Device bei jedem Start automatisch mit einem variablen Key verschüsseln.

Dazu reicht folgender Eintrag in /etc/conf.d/dmcrypt:

swap=cryptswap
source='/dev/sda2'
key='/dev/urandom'
options='--allow-discards'

Der Wert für "source" ist hier natürlich anzupassen. Bei mir ist es /dev/sda2 und options='--allow-discards' ist bei mir mit an Board, weil mein swap-Device ebenfalls auf der SSD liegt. Soll es hier auf einer herkömmlichen HDD liegen, ist --allow-discards nicht erforderlich.

In /etc/fstab wird die verschlüsselte swap-Partition dann einfach eingebunden:

/dev/mapper/cryptswap none swap sw 0 0


Vielleicht hilft es ja dem einen oder anderen ...

Geschrieben von cryptosteve | Kommentieren
Translate article to english

25.01.2015 um 17:42:34

Abgelegt in Gentoo, Linux

Kurztip: kmix Schrittgröße ändern

Ohne Kommentare

Auf einem frisch eingerichteten Debian testing (»Jessie«) ist die Lautstärke in der Standardeinstellung brüllend laut. Das ist ok und der Mixer kann dementsprechend weit runtergeregelt werden. Leider ist die Schrittgröße ("step size") in Kmix unter Debian standardmäßig recht groß und kann nach heutigem Stand über die Kmix-GUI auch nicht geändert werden.

Abhilfe schafft hier das Beenden von Kmix mit anschließendem Editieren der ~/.kde/share/config/kmixrc. Dazu ist der oberen Section "Global" einfach folgender Eintrag hinzuzufügen:


[Global]
[ ... ]
VolumePercentageStep=1.8

Welchen Wert man für VolumePercentageStep muss jeder für sich selbst entscheiden und hängt vermutlich auch von den verwendeten Boxen bzw. Kopfhörern ab. Ein Wert von 2.5 erwies sich hier als noch immer zu groß, sodass ich mich für 1.8 entschieden habe.

Nach dem Ändern der kmixrc kann Kmix wieder gestartet werden und arbeitet fortan mit den neuen Lautstärke-Schrittgrößen.

Geschrieben von cryptosteve | Kommentieren
Translate article to english

15.01.2015 um 19:50:15

Abgelegt in Linux

Weitere Tips zur Ubuntu-Einrichtung

Mit 2 Kommentaren

Bereits in diesem Beitrag habe ich einige Tips zur Einrichtung von Ubuntu aufgeschrieben. Vielmehr handelt es sich eigentlich um Stolpersteine, die mir selbst im Weg lagen.

Nun stelle ich erneut eine Maschine auf Ubuntu 14.04 um und wieder ergeben sich einige Probleme, die ich mittlerweile lösen konnte. Zum Zwecke der Dokumentation hier die Lösungswege:

Problem: Bei einem lvm/luks verschlüsselten System wird nach dem ersten Reboot die Verschlüsselungspassphrase in einem schicken Kästchen abgefragt. Nach der Installation eines proprietären Grafikkartentreibers (NVidia und wohl auch ATI) ist die Auflösung in diesem Startscreen komplett hinüber und von plymouth ist nicht viel mehr als eine hässliche völlig deplazierte Schrift übrig.

Lösung: Der Framebuffer muss wieder aktiviert und mit der richtigen Auflösung angesteuert werden. Bei mir haben folgende Befehle und Einstellungen geholfen:

in /etc/default/grub folgende Ergänzung:

GRUB_GFXPAYLOAD_LINUX=1920x1200

(1920x1200 ist die Auflösung meines Monitors/framebuffers - es können nur solche Auflösungen verwendet werden, die auf dem grub-prompt via 'videoinfo' ausgegeben werden)

und dann nachfolgende Befehle:

$ echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash
$ sudo update-grub2
$ sudo update-initramfs -u





Problem: Fenster erscheinen nicht mittig, sondern zufällig/intelligent

Lösung: Zunächst muss der compizconfig-settings-manager installiert werden:

$ sudo apt-get install compizconfig-settings-manager


Diesen dann über den Befehl ccsm starten und dort im Modul FensterverwaltungFenster platzieren die entsprechende Einstellung von beim "Platzierungsmodus" von Intelligent auf Zentiert (oder was immer hier beliebt) setzen.

Zudem können über den Reiter "Fixed Window Placement" bestimmte Fenster auch an bestimmte Positionen und in bestimmte Modi gezwungen werden:



... to be continued ...

Geschrieben von cryptosteve | Kommentieren
Translate article to english

11.01.2015 um 20:18:16

Abgelegt in Linux

Kurztip: lokale Namenauflösung unter Debian

Ohne Kommentare

Wenn auf einem Linux (hier: Debian jessie) die Namenauflösung über den Hostnamen, nicht aber über den Domainnamen funktioniert, und die /etc/hosts und /etc/resolv.conf augenscheinlich richtig konfiguriert sind, dann solltet ihr prüfen, ob vielleicht die folgende Zeile in der Datei /etc/nsswitch.conf. wie folgt zu ändern ist ....

Und zwar von:

hosts: files mdns4_minimal [NOTFOUND=return] dns

in

hosts: files dns mdns4_minimal [NOTFOUND=return]


Alte Situation:

$ ping -c 1 reed
PING reed.crashmail.local (192.168.1.101) 56(84) bytes of data.
64 bytes from reed.crashmail.local (192.168.1.101): icmp_seq=1 ttl=64 time=0.260 ms
[ ... ]

$ ping -c 1 reed.crashmail.local
ping: unknown host reed.crashmail.local


Neue Situation:


$ ping -c 1 reed
PING reed.crashmail.local (192.168.1.101) 56(84) bytes of data.
64 bytes from reed.crashmail.local (192.168.1.101): icmp_seq=1 ttl=64 time=0.291 ms
[ ... ]

$ ping -c 1 reed.crashmail.local
PING reed.crashmail.local (192.168.1.101) 56(84) bytes of data.
64 bytes from reed.crashmail.local (192.168.1.101): icmp_seq=1 ttl=64 time=0.247 ms


Bei Gentoo funktioniert es übrigens out of the box.

Geschrieben von cryptosteve | Kommentieren
Translate article to english

08.11.2014 um 00:27:32

Abgelegt in Linux

IPFire löst die FRITZ!Box 7270v2 ab

Ohne Kommentare

Seit Jahren verrichtet die FRITZ!Box 7270v2 hier treu ihren Dienst. Auf das Gerät selbst kann ich nicht verzichten, weil ich im Consumerbereich bislang keine vergleichbare Telefonanlage gefunden habe. Der netzbasierte Teil der Box geriet in den letzten Wochen und Monaten allerdings vermehrt in die Kritik, als zunehmend Sicherheitslücken auftraten. Zudem ist die Box mittlerweile in einem Alter, in dem ich nicht nur mit technischen Problemen zu kämpfen habe (das integrierte DSL-Modem verweigert in unregelmäßigen Abständen den Dienst), sondern auch die Intervalle für Software-Updates zunehmend größer werden. Klar. AVM ist ein gewinnorientiertes Unternehmen und die Flagschiffe werden zuerst bedient.

Wie durch Zufall kam gerade der Roland des Weges und erzählte von einer Firewalldistribution namens IPFire, die er demnächst mal testen wolle. Ich hatte gerade Urlaub und nichts besseres vor und so war eine Hardwarebestellung schnell zusammen geklickt. Einige Tage später wurden die Einzelteile geliefert und trotz der recht knappen Abmessungen der Komponenten stand die fertige Kiste eine Stunde später vor mir. Die aktuelle Konfiguration könnt ihr übrigens meinem fireinfo.ipfire.org-Profil entnehmen.

Die Installation von IPFire gestaltet sich in einem ncurses-basierten Installer recht zügig. Es ist allerdings von Vorteil, wenn man grundlegende Kenntnisse von Netzwerktopologie hat und schon vorher eine ungefähre Idee hat, wie sein zukünftiges Setup aussehen soll.

So betreibe ich meine IPFire-Box mit vier Zonen, green0 für das interne Netzwerk, blue0 für den WLAN-Accesspoint, orange0 für die DMZ und natürlich red0 für den Internet-Zugang (=DSL-Modem). Durch die Bezeichnung der Devices mit Farbnamen läuft man gerade in der anfänglichen Konfiguration nicht so leicht Gefahr, mit den IPs der Netze und Subnetze durcheinander zu geraten.

Dabei trennt die IPFire-Box die Netze vernünftig auf und verhindert, dass beispielsweise Zugriffe aus der DMZ auf die internen Netze möglich sind. Der exakte Default kann dem IPFire default zone ruleset entnommen werden. IPFire bietet dabei diverse Dienste an, wie z.B. einen dhcp-Server, leicht zu konfigurierenden (auf Wunsch transparenten) Proxy, QoS und vieles mehr. Durch ein Addon-System können die Dienste darüber hinaus erweitert werden. So konnte ich meinen transparenten Proxy reicht einfach um einen Virenschutz via squidclamav erweitern. Da ich das Setup squid + squidclamav bereits manuell auf meinem Heimserver laufen hatte, kann ich nur sagen: das Setup via IPFire ist echt einfach und narrensicher.

Meine alte FRITZ!Box ließ sich zudem glücklicherweise als reiner IP-Client betreiben, sodass diese an orange0 in der DMZ noch immer ihren Dienst versieht und einige der alten WLAN-Geräte mit Netzzugang versorgt.

Der Aufbau meiner Netzwerke hier ist überdies noch deutlich komplizierter, weil auch noch andere Devices wie z.B. mein Freifunk-Router ihren Platz abgekommen haben. All diese Aufgaben erledigt die IPFire-Box aber bislang völlig anstandslos und zur vollen Zufriedenheit.

Geschrieben von cryptosteve | Kommentieren
Translate article to english

02.09.2014 um 10:28:42

Abgelegt in Internet, Linux