Dok.: 2021/001: Ein neuer Anfang!

Ja, ihr seht es bereits, ein neues Layout. Alles neu, es war Zeit für Veränderung.

Das neue Layout wirkt natürlich erstmal altbacken, aber das war auch die Absicht dahinter. In all den Jahren habe ich oft meine Homepage neu gebaut, manchmal sogar quartalsweise komplett das Design geändert, ebenso auch oft den Unterbau komplett ersetzt.

Dieses Mal habe ich aber einen anderen Ansatz verfolgt. Nach so vielen Jahren im IT-Umfeld bin ich privat immer mehr ein Fan der Offline-Welt geworden. Es muss und sollte einfach nicht zu viel digitalisiert werden. Daher bin ich nun auch in das Hobby der Schreibmaschinen gerutscht, welches ich mit dem neuen Layout meiner Homepage nun in die digitale Welt übertrage.

In nächster Zeit werde ich also ein wenig über Schreibmaschinen berichten/erzählen. Nicht nur in Text und Bildern, sondern auch für Youtube möchte ich ein paar Filmchen produzieren.

Nach wie vor aktuell ist aber auch das Thema Linux. Dem möchte ich mich auch wieder intensiver widmen und habe bereits mit dem Bau meiner eigenen Linux-Distribution begonnen.

Also seid gespannt und freut euch, die Zukunft wird großartig. Zumindest theoretisch. :)

Dok.: 2017/001: GPG / PGP: Web of Trust - Eine kleine Liebesgeschichte

Da GPG/PGP auf dem Web of Trust basieren, ist es recht schade, dass dieses "Feature" fast gar nicht genutzt wird, obwohl sich damit sogar die Sicherheit steigern ließe.

Wer regelmäßig PGP einsetzt und damit auch ab und an mal neue Kommunikationspartner hinzufügt, hat natürlich erstmal nur deren öffentliche Schlüssel von einem Keyserver, als Anhang einer Mail oder auch von deren Homepage. Aber wie sicher kann man sein, dass dieser öffentliche Schlüssel auch tatsächlich der Person gehört?

In der echten Welt sollte man sich nicht einfach darauf verlassen, dass die Schlüssel auf dem Keyserver die echten sind, die Mail samt Schlüssel im Anhang nicht von einem falschen Absender gefaked wurde oder auch die Homepage des Kommunikationspartners auch tatsächlich seine ist und dort nicht der Schlüssel getauscht wurde.

Deshalb gibt es ja die Empfehlung, die Fingerprints eines Schlüssels privat von Angesicht zu Angesicht zu vergleichen und dann den Schlüssel des jeweils anderen zu signieren. Theoretisch geht das auch telefonisch, wenn man sich gut genug kennt und anhand der Stimme oder bestimmter Codewörter den anderen eindeutig identifizieren kann. Videochat ist ebenfalls ein Option.

Eine kleine Liebesgeschichte

Damit hat man schon eine Verbindung zwischen 2 Personen erzeugt. Nennen wir sie mal Alicia und Bobby. Nun treffen sich Bobby und Alicia mal auf der Straße und Bobby verliebt sich dabei in Alicias Freundin Chantaline. Er will ihr später einen verschlüsselten Liebesbrief schicken, damit auch nur Chantaline das Geschnulze lesen kann.

Er erfährt ihre Mail-Adresse, kann somit auch auf einem Keyserver z.B. einen Pub-Key dafür finden. Woher weiß er nun aber, dass der Key wirklich ihrer ist? Wenn er seinen Liebesbrief für den Key verschlüsselt, entschlüsselt den Brief womöglich doch jemand anders, weil die Familie sich eine Mail-Adresse teilt (ja, sowas gibt's!), z.B. Chantalines Mutter. Oder schlimmer noch: ihr Vater. Oh oh!

Aber zu Bobbys Glück hat er ja bereits Alicia in seinem Keyring. Und Alicia schickt oft Katzenbilder mit Chantaline hin und her, natürlich verschlüsselt und signiert. Und weil Alicia eine ganz Nette ist, hat sie sogar Chantalines Key signiert, was Bobby auch sehen kann.

Na, das ist doch schonmal was. Damit kann Bobby sich nun schon recht sicher sein, dass der Key auch wirklich stimmt. Außerdem sieht Bobby auch, dass Chantalines Key bereits von seinem Freund Dave signiert wurde. Und weil Dave so ein Wilder ist, kann Bobby sich auch ziemlich sicher sein, dass Dave die Chantaline schon ihrer Entropie beraubt hat.

Aber Bobby weiß ja, dass Alicia in nem Cheerleader-Team eines Schachvereins tanzt und dort paar weitere heiße Schnittchen auf Verschlüsselungspartner warten. Bobby findet da auch fix viele Mail-Adressen anderer Cheerleader, deren Keys er seinem Keyring hinzufügt. Aber jede einzelne davon jetzt separat zu verifizieren wäre ja echt anstrengend.

Aber auch da kommt nun Alicias Key ins Spiel. Weil Bobby nämlich den Trust für Alicia so definiert, dass er ihr sehr stark vertraut, dass Alicia nur persönlich überprüfte Keys signiert, sieht er sofort auch, wie vertrauenswürdig die Schlüssel der Cheerleader sind.

Um nicht nur die Vertrauenswürdigkeit der Schlüssel, sondern auch deren Gültigkeit zu verifizieren, kann Bobby auch noch eine Trust-Signatur für Alicia ausstellen, mit Level 1. Das bedeutet, dass sein GPG/PGP automatisch auch alle Schlüssel als gültig anerkennt, die Alicia signiert hat. Ist das nicht praktisch?!

Und so hilft das Web of Trust dem schüchternen, romantischen Bobby, verschlüsselte Liebesbriefe per Serienbrief an alle Cheerleader zu verschicken. Und Bobby hinterlässt seine Fingerprints an ihren Keygrips. Das ist natürlich nur ein Wortspiel und technisch totaler Quatsch, soll aber ein Happy End suggerieren.

Lasst uns trusten!

So, damit ihr nun auch in die glückliche Situation von Bobby geraten könnt, plane ich den Aufbau einer eigenen "Alicia". Dafür generiere ich einen RSA 4096 und einen ECDH (cv25519) Key. Mit diesen 2 Keys (ich nenne sie mal WoT-Keys) werde ich gerne eure Keys signieren, sodass wir ein kleines Web of Trust aufbauen können. Und wer weiß, dadurch ergeben sich vllt. auch ganz neue Kontakte und Gespräche.

Warum ich 2 Keys verwenden werde? Nunja, ist einfach erklärt. ECDH Keys mit Curve25519 werden erst seit GnuPG 2.1 unterstützt. Und da viele Leute noch auf 2.0 oder gar älter festhängen (aufgrund ihrer Distro z.B.), können diese den RSA Key verwenden. Alle mit modernem GnuPG können stattdessen den ECDH Key nutzen, da dort die Signaturen viel kleiner sind, was natürlich ein bisschen Ressourcen spart (CPU, RAM, Speicher).

Außerdem - sollte irgendwann in der Zukunft eines der beiden Verfahren kryptographisch unbrauchbar werden, weil es dann nicht mehr sicher ist - bleibt noch das andere Verfahren als Sicherheit erhalten. Außerdem könnte so ein Missbrauch auffallen, falls ein Key nur mit einem der beiden Keys signiert wurde.

Damit ich anschließend eure Keys signiere, wird es einen festen Ablauf geben:

  1. Ihr schickt mir euren zu signierenden Pub-Key und ein paar Infos an meine persönliche Mail-Adresse
  2. Ich schreibe an jede Mail-Adresse in eurem Key eine verschlüsselte Mail mit unterschiedlichen Passwörtern
  3. Wir machen einen Videochat, bei dem ihr mir euren Personalausweis zeigt, damit ich euren Namen bestätigen kann
  4. Ebenfalls nennt ihr mir beim Videochat die Passwörter, die ihr erhalten habt
  5. Ich signiere anschließend mit meinen 2 WoT-Keys die UIDs in eurem Key, die ich korrekt bestätigen kann
  6. Ihr erhaltet euren von mir signierten Key per Mail zurück

Darüber hinaus bin ich am Überlegen, ob ich auf irgendeine Art und Weise jährlich von euch bestätigen lasse, dass ihr die Keys noch nutzt und die Mail-Adressen tatsächlich noch euch gehören.

Auf jeden Fall wird das alles manuell von mir persönlich durchgeführt, ich werde da keinen Automatismus oder sonstwas für bauen. Ich habe außerdem ein speziell nur für diesen Zweck vorhandes Gerät mit einem gehärteten Linux, verschlüsselter Festplatte und etlichen weiteren Sicherheitsvorkehrungen, damit da auch wirklich niemand sonst an die Private Keys rankommt.

Dok.: 2016/001: Sichere Homepage mit Let's Encrypt

Dank Let's Encrypt kann sich nun jeder kostenlos SSL-Zertifikate für die eigene Homepage signieren lassen, die dann von allen aktuellen Browsern auch anerkannt werden.

Qualys SSL Labs bieten eine Überprüfung der Webseite und des Zertifikats, berücksichtigen dabei die Stärke der Verschlüsselung, Anfälligkeit für Schwachstellen und insgesamt die Konfiguration des Dienstes. Die bestmögliche Bewertung ist ein A+.

SSL Labs A+ b-root-force.de

Den kompletten Testbericht meiner Domain seht ihr hier: https://www.ssllabs.com/ssltest/analyze.html?d=b-root-force.de

Zertifikat erstellen

Wenn ihr auf eurem System den letsencrypt-Client installiert habt, dann könnt ihr euch damit ein Zertifikat erstellen, dieses automatisch von Let's Encrypt signieren lassen und gleichzeitig euren Webserver konfigurieren lassen.

Ich selbst bevorzuge dabei, meinen Webserver manuell zu konfigurieren. Deshalb verwende ich folgenden Befehl:

letsencrypt certonly --standalone --rsa-key-size 4096 -d b-root-force.de -d www.b-root-force.de -d gentoo.b-root-force.de

Dazu war aber notwendig, dass ich kurzzeitig mein nginx beende, da letsencrypt für die Überprüfung der Domains selbst einen kleinen Webserver auf Port 80 startet.

Wenn ihr '--rsa-key-size 4096' weglasst, dann wird standardmäßig nur ein 2048 bit Schlüssel erstellt. Das reicht auch aus und ist performanter, bringt beim SSL Labs Test dann aber bei *Cipher Strength* keine 100%. Da ich aber keine hunderte Besucher am Tag habe, ist mir die Performance nicht so wichtig. Bei wirklich sensiblen Sachen wie Shops oder Banking würde ich die stärkere Verschlüsselung aber auch der Performance vorziehen.

Ihr dürft natürlich nicht vergessen, alle eure Domains dort anzugeben. Also die Haupt-Domain jeweils mit und ohne www. und dann alle weiteren Subdomains.

Die Zertifikate werden dann in '/etc/letsencrypt/live/[domain]' abgelegt, in meinem Fall also '/etc/letsencrypt/live/b-root-force.de'

Dann benötigt man noch eine Datei für den DH-Algorithmus. Diesen erzeuge ich mit ebenfalls 4096 bit, normal reicht aber auch 2048:

openssl dhparam -outform PEM -out /etc/letsencrypt/live/b-root-force.de/dhparam.pem 4096

nginx

Nun muss man nur noch nginx entsprechend konfigurieren. Dazu lege ich eine Datei an: '/etc/nginx/ssl.conf':

listen 443 ssl; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"; add_header X-Frame-Options SAMEORIGIN; ssl_session_timeout 10m; ssl_session_cache shared:SSL:50m; ssl on; ssl_stapling on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ecdh_curve secp384r1; ssl_certificate /etc/letsencrypt/live/b-root-force.de/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/b-root-force.de/privkey.pem; ssl_dhparam /etc/letsencrypt/live/b-root-force.de/dhparam.pem; # nur 256 bit Verschlüsselung erlauben: ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA; # 128 & 256 bit Verschlüsselung erlauben (wenn Performance eine Rolle spielt): #ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA;

In meiner '/etc/nginx/nginx.conf' passe ich dann entsprechend meine Konfiguration an:

server { listen 80; server_name www.b-root-force.de b-root-force.de; return 301 https://; } server { include ssl.conf; server_name www.b-root-force.de b-root-force.de; ... }

Damit werden alle Aufrufe über HTTP direkt auf HTTPS umgeleitet. Durch den Header 'Strict-Transport-Security' wird dem Browser mitgeteilt, dass er zukünftig meine Seite nur noch per HTTPS aufrufen soll. Wenn man zukünftig wirklich plant, immer alle Seiten per HTTPS anzubieten, dann kann man sich ebenfalls hier eintragen: https://hstspreload.appspot.com. Dann werdet ihr in eine öffentliche HSTS Preload Liste eingetragen, bei der sich Chrome, Firefox, IE und Edge bedienen. Wenn dann ein Besucher das allererste Mal auf eure Seite geht, wird sein Browser ihn direkt auf HTTPS schicken.

Dann halt nginx einmal neustarten und testen. Da die Let's Encrypt Zertifikate nur 90 Tage gültig sind, solltet ihr natürlich nicht vergessen, sie rechtzeitig neu zu generieren. Am besten die dhparam.pem auch. Und den nginx Neustart nicht vergessen. :)

Eine ausführlichere und auch technisch detailliertere Anleitung findet ihr auf der Seite von Stephan Herbers: Sichere NGINX TLS Konfiguration