Reportage über die Arbeit auf einem Unterseeboot der Bundesmarine von Peter Hertling.
Erstausstrahlung 1980.
Archiv des Autors: sommteck
Bahn-Ansage
Einen sehr angenehmen und amüsanten Twitter-Account den ich folge ist Bahnansagen. Dort werden allerlei Sprüche gepostet, welche die Zugbegleiter bei ihrer täglichen Arbeit hin und wieder durch die Zugdurchsagen verbreiten. Heute hatte ich auch mal das Glück, einen dieser gut gelaunten Mitarbeiter während meiner Fahrt mit dem Regionalexpress von Regensburg nach Nürnberg anzutreffen. Folgende Situation ergab sich.:
Die Schaffnerin erreichte während ihrer Fahrkartenkontrolle die Vierer-Sitzgruppe in der ich saß. Die eine junge Frau mir gegenüber überreichte der Bahnmitarbeiterin ihren Fahrschein und bat diese, doch ihren Kugelschreiber für sich selbst mal kurz zu verleihen, damit sie ihren Ausweis – vermutlich einen Studentenausweis oder es war auch die BahnCard – noch schnell unterschreiben kann. Darauf bemerkte die Schaffnerin ganz spöttig: „Über den Bistro-Service ist dann später ein Kaffee nach zu reichen. – Denn das ist günstiger als die 7,50€ Strafgebühr für das nicht Bereithalten eines gültigen Ausweisdokumentes. Der Kaffee ist hier meistens schön stark.“
Schön, wenn das Zugpersonal die Fahrgäste auf ihren formalen Misstand so charmant hinweisen und Kulanz zeigen.
Kobo Hacking Teil 2 – Bilder anzeigen
Da der Kobo-Mini über ein Touch-Display mit 800×600 Pixel verfügt, müssen Bilder erst einmal mit GIMP auf diese hinunter skaliert und in ein PNG-Datei mit 16 Graustufen (4 Bit) umgewandelt werden.
Anschliessend müssen die Bilder mit ffmpeg wieder in ein RAW-Format konvertiert werden.
ffmpeg -v quiet -vcodec png -i test.png -vcodec rawvideo -f rawvideo -pix_fmt rgb565 test.raw
Ist eine fertige Bilddatei auf den Kobo hinüber kopiert, so lässt sie sich mit:
cat test.raw | /usr/local/Kobo/pickel showpic
auf dem kleinen eBook-Reader darstellen.
Als ersten kleinen Hack habe ich mal ein paar Bilder umgewandelt und ein ganz simples Shell-Skript gebastelt, welches diese mit einer Zeitverzögerung in einer Endlosschleife darstellt. Somit lässt sich der Kobo als Digitalen Bilderrahmen umfunktionieren. – Wenn auch nur in schwarz-weiß.
#!/bin/sh while true do cat /mnt/onboard/Pictures/test01.raw | /usr/local/Kobo/pickel showpic sleep 60 cat /mnt/onboard/Pictures/test02.raw | /usr/local/Kobo/pickel showpic sleep 60 cat /mnt/onboard/Pictures/test03.raw | /usr/local/Kobo/pickel showpic sleep 60 cat /mnt/onboard/Pictures/test04.raw | /usr/local/Kobo/pickel showpic sleep 60 cat /mnt/onboard/Pictures/test05.raw | /usr/local/Kobo/pickel showpic sleep 60 done
Angekommen im HQ 3.0
Bereits Ende Februar verließ das Hackquarter des CCC-Frankfurt seine alten Räumlichkeiten in der Kommunikationsfabrik um die neuen in der Häuser Gasse zu beziehen. Hintergrund war, dass das alte Quartier gerade in Hinblick auf den öffentlichen Donnerstagstreff irgendwann zu klein gewesen ist. So bestand der Wunsch, sich neuere und vor allem größere Räumlichkeiten zu suchen, um auch mit der Anzahl an Mitgliedern sowie der Unterbringung weiterer Gerätschaften expandieren zu können. Man hatte sich im Neuen dann zwar schnell eingelebt, aber so ganz perfekt war es dennoch nicht. Nach einem Provisorium wurde über das Frühjahr noch eine adequate, gebrauchte Küche besorgt um auch Möglichkeiten zum Food-Hacking für das Hackquarter zu schaffen. Nachdem auch diese Anstrengung nun zurück liegt, lag es nahe, das neue HQ auch offiziel einzuweihen und dies gebührlich zu feiern. Anlässlich dazu fand deswegen am vergangenen Samstag den 4. Juli die Einweihungsparty in der Häuser Gasse statt, welche sehr erfolgreich war. Es gab viel Spiel, Spaß und Trunk zu der reichlich Gäste der Einladung gefolgt sind.
In diesem Sinne kann man den CCC-Frankfurt für die Zukunft nur alles Gute und viele neue Menschen mit vielen neuen Ideen wünschen.
Erstellen eines eigenen SSL-Server-Zertifikates
Nachdem ich mir vor sechs Wochen wieder ein vServerchen geleistet habe um meinen Senf in diesem Blog ablassen zu können, bin ich für mich mal die Frage durchgegangen wie ich das mit der Transportverschlüsselung löse. Denn früher hatte ich das nämlich bei dieser Domain noch nicht getan. Für mich war ganz klar, dass ich über meinem ISP keine zusätzliche 50,- Euro für ein von einer offiziellen Zertifizierungsstelle signiertes SSL/TLS-Zertifikat jährlich ausgeben werde. Die Lösung des Ganzen befindet sich sowieso in Form eigener Bordmittel in jedem Linux oder lässt sich im Zweifel auch auf anderen Systemen nachinstallieren. Im nachfolgenden werde ich meine eigene CA erstellen, um mir mein eigenes SSL-Zertifikat erzeugen zu können.
1. Erstellen der CA
Ist OpenSSL – beziehungsweise als Alternative neuerdings gerne auch LibreSSL – auf dem Rechner installiert, ist es mal der Ordnung halber praktisch sich einen Ordner ca anzulegen, wo die Dateien abgelegt werden sollen.
root@linux# mkdir /root/ca root@linux# cd /root/ca
Die Gültigkeit setze ich mit 10 Jahren bewusst erst einmal sehr hoch an. Läuft die CA aus, so werden nämlich auch alle damit signierten Serverzertifikate ungültig. Die CA enthält einen geheimen Schlüssel, welcher automatisch erzeugt und in der Datei cakey.pem abgelegt wird. Das CA-Zertifikat wird nach cacert.pem geschrieben. Der folgende Befehl erzeugt einen Schlüssel für das Zertifikat mit einer Länge von 2048 Bit:
root@linux# openssl req -new -x509 -newkey rsa:2048 -keyout cakey.pem -out cacert.pem -days 3650 Generating a 2048 bit RSA private key .............................................................. .............................................................. .........................................+++ ......................................+++ writing new private key to 'cakey.pem'
Wer den geheimen Schlüssel der CA kennt, kann damit beliebige Serverzertifikate signieren. Deshalb wird diese Schlüsseldatei nicht im Klartext auf der Festplatte abgelegt, sondern mit einer Passphrase verschlüsselt. Diese Passphrase benötigt man immer dann, wenn mit dieser CA neue Zertifikate ausgestellt werden sollen.
Danach wird man gebeten, Daten einzugeben, welche die CA identifizieren. Diese werden dem Client angezeigt, wenn er aufgefordert wird, das Zertifikat zu akzeptieren oder abzulehnen. Der Code für Deutschland ist DE. Wenn ein Feld leer bleiben soll, so reicht es, einen Punkt ein zu geben. Ansonsten wird der in eckigen Klammern stehende Defaultwert eingetragen.
Das Feld Common Name (CN) ist hier der offizielle Name der Zertifizierungsstelle. Für die eigene CA reicht es, den eigenen Namen einzutragen.
Am Ende sind dann die Dateien cacert.pem und cakey.pem entstanden.
Vorsichtshalber sollten man die Rechte so setzen, dass die Schlüsseldatei nur für root lesbar ist.:
root@linux# chmod 600 cakey.pem
Mit dem Befehl
root@linux# openssl rsa -in cakey.pem -noout -text
kann man nun einmal prüfen, ob sich der Schlüssel mit der Passphrase öffnen lässt.
2. Schlüssel für das Serverzertifikat erzeugen
Nachdem nun die eigene CA vorhanden ist, kann diese nun endlich eigene Zertifikate herausgeben. Dazu wird zunächst ein 2048 Bit langer RSA-Schlüssel erzeugt, welcher mit AES 256 verschlüsselt auf der Platte abgelegt wird. Die Passphrase muss diesmal nicht sonderlich geheim sein, da sie ohnehin im Anschluss wieder entfernt wird. OpenSSL lässt allerdings keine leere Phrase zu.
root@linux# openssl genrsa -out serverkey.pem -aes256 2048 -days 3650
Jetzt ist es ganz praktisch die Passphrase wieder zu entfernen, da der Server auch ohne Zutun des Administrators in der Lage sein soll, den Schlüssel zu lesen. Sonst müsste bei jedem Booten der Machine ein Passwort eingegeben werden.
root@linux# openssl rsa -in serverkey.pem -out serverkey.pem
3. Certificate Signing Request erzeugen
Der nächste Schritt zum eigenen Zertifikat ist ein CSR. Dies muss dann nur noch von der CA signiert werden. Hier sind wieder Angaben analog zum Erstellen der CA nötig, was oft Verwirrung stiftet. Die allgemeinen Daten kann man gegebenfalls gleich wie oben eingeben.
root@linux# openssl req -new -key serverkey.pem -out req.pem -nodes
ACHTUNG, jetzt kommt das Wichtige: Beim Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name stehen, unter dem der Client den Server anspricht! Wird das Zertifikat für eine HTTPS-Verbindung zu www.domain.tld verwendet, so muss der Common Name eben genau www.domain.tld heißen. Andernfalls wird der Browser das Zertifikat nicht akzeptieren, da er davon ausgehen muss, auf dem falschen Server gelandet zu sein.
Common Name (eg, YOUR name) []: www.domain.tld Email Address []: name@domain.tld
Weitere Optionen kann man einfach leer lassen.
A challenge password []: An optional company name []:
4. OpenSSL-Konfiguration anpassen
Leider kann man bei OpenSSL nicht alle Daten als Kommandozeilenargumente übergeben. Einige Einstellungen müssen lästigerweise in der Datei /etc/ssl/openssl.cnf geändert werden, bevor man signieren kann. Dazu die Datei öffnen und folgende Zeilen in der Sektion [ CA_default ] anpassen.
dir = . # Where everything is kept new_certs_dir = $dir # default place for new certs private_key = $dir/cakey.pem # The private key RANDFILE = $dir/.rand # private random number file default_days = 3650 # how long to certify for
Das Feld default_days ist auf 365 Tage voreingestellt und gibt die Gültigkeit des Zertifikates an. Dieses setze ich wie im Beispiel auf 10 Jahre herauf.
Wenn bei dem Serverzertifikat kein Bundesstaat angegeben ist, wird folgende Änderung unter [ policy_match ] benötigt.
stateOrProvinceName = optional
Nun muss man noch einige Dateien anlegen:
root@linux# echo 01 > serial root@linux# touch index.txt
5. Serverzertifikat signieren
Als krönenden Abschluss signiert die eigene CA nun das Zertifikat
root@linux# openssl ca -in req.pem -notext -out servercert.pem
6. Zertifikate installieren
Wohin die erzeugten Zertifikate installiert werden sollen, hängt vom jeweiligen Serverdienst ab. Was ihnen aber allen gemeinsam ist, es werden nur die Dateien cacert.pem, servercert.pem und serverkey.pem benötigt. Die Datei cakey.pem wird nicht benötigt und sollte nicht auf dem Server liegen sondern am besten sicher auf einem anderen Rechner verwahrt werden.
Da es sich bei den Dateien im wesentlichen nur um Textdateien handelt, ist es prinzipiell egal wie sie heißen. Der Übersicht halber und zur besseren Ordnung kann man sie aber auch im Nachhinein in eine umgänglichere Form unbenennen.
cacert.pem -> ca.crt
servercert.pem -> server.crt
serverkey.pem -> server.key
Jetzt sind das aber alles keine neuen Erkenntnisse. Im letzen Jahr erst wurde mit Let’s Encrypt eine alternative Zertifizierungsstelle ins Leben gerufen, um für alle Server-Betreiber kostenlose Zertifikate anbieten und ausstellen zu können. Diese wird unter anderem von der Mozilla und der Electronic Frontier Foundation gesponsert. Man wird sehen wie sich das entwickeln wird.