DANE ist ein noch rar gesätes Protokoll, das Domainnamen mit einem oder mehreren TLS-/SSL-Zertifikaten verknüpft. Durch das DNS wird dem Client diktiert, welche Sicherheitszertifikate für eine Domain gültig sein sollen. Hintergrund ist, dass jede große, anerkannte CA der Welt (und davon gibt es hunderte) theoretisch für jede Domain gültige TLS-Zertifikate ausgeben kann. Dass das viel Spielraum für Manipulation und Missbrauch bietet, liegt auf der Hand. Indem man im DNS Informationen dazu ablegt, welche einzelnen Zertifikate oder Zertifizierungsstellen (CAs) für die Domain genutzt werden dürfen, kann man die Sicherheit signifikant verbessern. Normalerweise wird DANE in Kombination mit DNSSEC (Internetstandard zur Absicherung von DNS-Zonen) eingesetzt. Prinzipiell ist DNSSEC für die Nutzung von DANE nicht zwingend erforderlich. Es stellt sich jedoch die Frage, ob es sinnvoll ist, DANE Informationen in einer nicht manipulationssicheren Zonendatei unter zu bringen … besser ist es, DANE mit aktiviertem DNSSEC zu nutzen.
Linux
DANE und TLSA DNS Records erklärt
Let’s Encrypt ACME Challenge Responses sammeln [Nginx]
Im Manual Mode des Let’s Encrypt Referenzclients muss jede Domain über eine individuelle Datei im Unterverzeichnis /.well-known/acme-challenge/ derselben Domain bestätigt werden. Bei vielen Domains bremst das Wechseln zwischen den Verzeichnissen und das erstellen der notwendigen Verzeichnisstruktur den Arbeitsablauf. Damit die Domains schneller bestätigt werden können, sammle ich alle ACME Responses in einem gemeinsamen Verzeichnis /var/www/acme-challenges/. Egal, welche Domain gerade bestätigt werden soll: Die Datei zur Bestätigung wird hier abgelegt und steht dennoch unter der gewohnten URL bereit. Und so geht’s:
Let’s Encrypt Zertifikate mit Public Key Pinning und DANE
In mindestens zwei Anwendungsfällen ist die geringe Laufzeit von Let’s Encrypt Zertifikaten lästig: Bei der Nutzung von HPKP (Public Key Pinning) und DANE. Beide Verfahren sollen HTTPS-Verbindungen zusätzlich absichern, indem genau spezifiziert wird, welche TLS-Zertifikate für eine Domain gültig sein sollen. Da mindestens alle 90 Tage ein anderes Let’s Encrypt -Zertifikat eingerichtet werden muss, müssen in diesem Zyklus auch die HPKP- und DANE-Einstellungen mehr oder weniger aufwendig aktualisiert werden.
Der Aufwand lässt sich jedoch mit einem Trick reduzieren: Da beide Verfahren auf der Untersuchung des Public Keys im öffentlichen Zertifikat beruhen, kann man dafür sorgen, dass sich dieser bei der Umstellung auf ein neues Zertifikat nichts ändert. Man verwendet daher bei der Beantragung eines neuen LE-Zertifikats also keinen neuen Private Key, sondern einen alten. (Der Public Key basiert auf dem Private Key). Um einen alten Key nutzen zu können, muss der Referenzclient von Let’s Encrypt im Zusammenspiel mit einem eigenen, gleich bleibenden Private Key und einer eigenen Zertifikatsanfrage (CSR) verwendet werden.
TOTP mit Yubikey auf Smartphone und Desktop
Die meisten Webdienste, die eine Zwei-Faktor-Authentifizierung anbieten, unterstützen das TOTP (Time-based one time password) -Verfahren. Dabei bleiben die Codes nur eine gewisse Zeit lang gültig und ändern sich ständig. Zugriff auf die Codes bekommt man bei den Yubikeys nur über eine dritte Software, die mit dem Yubikey kommuniziert. Das liegt daran, dass der Yubikey keine eigenständige Code-Berechnung ausführen kann, weil ihm für eine eigene Systemuhr die notwendige Energieversorgung fehlt. Die Berechnung des Codes geschieht immer im Yubikey selbst – die geheimen Schlüssel verlassen also niemals den Yubikey. Die Clientprogramme liefern dem Yubikey nur die Systemzeit, holen die fertig generierten Einmalcodes ab und zeigen sie an. „Yubikey Authenticator“ heißt der TOTP Client für den Yubikey, den es für Android, Linux, Windows und MacOS gibt.
Spamassassin Erkennungsrate verbessern mit mailbox.org Filtern
Wie bereits bekannt sein dürfte, kann man die Erkennungsrate von Spamassassin verbessern, indem man die Software von bereits als Spam markieren E-Mails mittels sa-learn lernen lässt.
Seit einigen Monaten binde ich in mein Spamassassin zusätzlich die Filterregeln von Heinlein Support ein, die täglich aktualisiert werden und vom Betreiber so 1:1 auch für mailbox.org verwendet werden. Seitdem hat sich die Erkennungsrate für Spam signifikant verbessert. Zu meinem bestehenden Cronjob zur Aktualisierung der allgemeinen Filterregeln habe ich einfach einen zweiten Cronjob für die Heinlein Support-Filterregeln hinzugefügt:
# crontab -e
Crontab Inhalt:
@hourly sa-update && systemctl reload spamassassin @hourly sa-update --nogpg --channel spamassassin.heinlein-support.de && systemctl reload spamassassin
(Falls kein systemctl (systemd) vorhanden, anpassen! service spamassassin reload)
Von Heinlein Support gibt es hier weitere Infos und eine Anleitung: https://www.heinlein-support.de/blog/news/aktuelle-spamassassin-regeln-von-heinlein-support/
Dass das Unternehmen seine Filterregeln frei für alle Admins zur Verfügung stellt, macht es durchaus sympathisch, finde ich. Vielleicht stellt in Zukunft ja auch der Mailprovider Posteo seine Filter zur Verfügung?
Fehlender U2F Support für Yubikey in Mozilla Firefox
Vor einiger Zeit habe ich mir einen Yubikey zugelegt, der u.A. die Authentifizierung über den U2F Industriestandard unterstützt. Bei Diensten wie Dropbox, GitHub oder Gmail kann man sich schon via U2F Mechanismus und einem U2F-kompatiblen Authentifizierungsgerät anmelden – aber bisher nur über den Google Chrome Browser. Andere Browser (und so leider auch Firefox) unterstützen U2F noch nicht, obwohl der erste Standard zu U2F – FIDO v1.0 – schon im Dezember 2014 verabschiedet wurde.
Ein Jahr ist jetzt vorüber und mein Lieblingsbrowser Firefox arbeitet noch immer noch mit meinem Yubikey zusammen. Im Mozilla Bugtracker gibt es eine Diskussion zu dem Thema und offenbar bin ich nicht der einzige, der FIDO U2F Support im Firefox schon sehnsüchtig erwartet. Gerüchten zufolge soll Firefox in etwa 3 Monaten endlich U2F unterstützen. Ich bin gespannt.
Passwortschutz von PDF Dateien entfernen
Einige Professoren an meiner Hochschule schützen ihre PDF Skripte mit einem Passwort, sodass sie von fremden Usern nicht geöffnet oder bearbeitet werden können. Da die ständige Passworteingabe im Alltag lästig ist, habe ich mich nach einer Möglichkeit umgesehen, den Passwortschutz zu entfernen – am besten direkt über die Kommandozeile.
Mit dem PDF-Tool qpdf kann der Passwortschutz sehr unkompliziert entfernt werden:
sudo pacman -S qpdf qpdf --password=geheim --decrypt mitpasswort.pdf ohnepasswort.pdf
Wahrscheinlich bin ich nicht der einzige, der von geschützten PDF-Dateien genervt ist – daher dachte ich, ich schreibe das hier mal auf.
Let’s Encrypt Zertifikate im Manual Mode abholen
Let’s Encrypt ist auf das automatische Abholen und Einrichten von TLS-Zertifikaten ausgelegt. Für Anwender, die mehr Kontrolle über den Prozess haben wollen, gibt es aber auch einen „Manual Mode“, der folgende Vorteile hat:
- Die Zertifikate können von jedem Rechner aus abgeholt werden (Der LE Client muss nicht auf dem Zielserver laufen)
- Der Webserver muss nicht wegen des LE Clients kurzzeitig abgeschaltet werden.
Und so funktioniert’s: Auf von einem beliebigen Rechner aus kann mit dem Let’s Encrypt ACME Client eine Zertifikatsanfrage abgeschickt werden. Zur Bestätigung des Domainbesitzes müssen in einem bestimmten Unterverzeichnis des Ziel-Webservers (Domain-Ziel) Dateien mit einem bestimmten Inhalt hinterlegt werden (=> Challenge-Dateien). Der ACME Server überprüft daraufhin, ob die Dateien unter den jeweiligen Domains erreichbar sind und der Inhalt korrekt ist. Wenn das der Fall ist, ist der Domainbesitz bestätigt und die Zertifikate werden ausgehändigt.