IT-Blog von Sebastian van de Meer

Kategorie: IT-Security (Seite 13 von 14)

Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.

Sicheres SSL / TLS Zertifikat

Es ist Zeit für ein neues Serverzertifikat. Im Standard sind dieses RSA Schlüssel mit einer Länge von 2048 Bit und SHA1 als Hash Algorithmus für Signaturen. Bei SHA1 bekommt man leider etwas Bauchschmerzen… 2048 Bit Keys sind nun ebenfalls nicht SO lang. Theoretisch noch „sicher“ aber wer will es schon darauf anlegen?

Nun wurde über Jahre an SSL / TLS Zertifikaten dieser Art festgehalten. Meist um kompatibel mit älteren Systemen zu sein. So können zum Beispiel die Betriebssysteme Windows XP sowie das darauf basierende Server Betriebssysteme von der Firma Microsoft, Windows Server 2003, nicht mit SHA2 umgehen.

Ich werde für die nächste Zertifikatsrunde auf 4096 Bit lange Schlüssel und SHA2 (SHA256) setzten. Selbst wenn ich damit einige Windows XP Benutzer abhängen werde!

Natürlich braucht man zusätzlich eine CA, welche mit X.509 Zertifikaten dieser Art umgehen kann. StartCOM / StartSSL kann dieses glücklicherweise. Ich erstelle die Zertifikate jeweils mit openSSL (Patch nicht vergessen!).

Key erstellen:

openssl req -new -outform PEM -out http.cert -sha256 -newkey rsa:4096 -nodes -keyout http.key -keyform PEM -days 730 -x509

Zertifizierungsanforderung (CSR) erstellen:

openssl req -new -key http.key -out http.csr -sha256

Die von er CA Unterzeichnete CSR einpflegen:

cat http.key http.crt > http.pem

Diffie Hellman Parameter erstellen und einfach mit ins pem werfen:

openssl gendh 4096 >> http.pem

Ja, es sind 4096bit für DH. dieses kann etwas dauern. Ist aber am Ende nötig damit zum Beispiel der Apache >=2.4 diese Bits auch nutzen kann!

Noch Fragen?

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

Der sichere GPG-Schlüssel

Absolut sicher ist nichts. Man kann nur versuchen, es Angreifern so aufwendig wie möglich zu machen. Bei GPG-Schlüsseln fängt das bei der Schlüssellänge und den Algorithmen an.

Schlüssellänge und Algorithmus

DSA-Schlüssel sind auf 512-1024 Bit begrenzt und anfällig bei schlechten Zufallsgeneratoren. ElGamal-Schlüssel können beliebig groß werden, teilen aber das Zufallsproblem. RSA mit 4096 Bit ist heute ein guter Kompromiss: rechenbar für aktuelle Hardware, nicht rechenbar für bekannte Angriffe. Quantencomputer könnten RSA in Zukunft gefährden, sind davon aber noch weit entfernt.

Unterstützte Verfahren anzeigen

gpg --version

Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

MD5 ist gebrochen, SHA1 gilt als unsicher. SHA-256 und SHA-512 sind die sinnvolle Wahl. Bei den symmetrischen Verfahren sind AES-256 und Twofish solide. 3DES bleibt als Fallback, weil GPG es als Pflichtverfahren mitführt.

Algorithmus-Präferenzen setzen

Man kann im eigenen Schlüssel festlegen, welche Algorithmen in welcher Reihenfolge bevorzugt werden. Die kurze Key-ID (0x0F9874D8) reicht dafür, auch wenn man für andere Zwecke besser die volle Fingerprint-ID nutzt.

gpg --edit-key 0x0F9874D8

Aktuelle Einstellungen anzeigen:

gpg> showpref
[ uneing.] (1). Sebastian van de Meer (E-Mail Address) kernel-error @ kernel-error.com;
Verschlü.: TWOFISH, AES256, AES192, 3DES
Digest: RIPEMD160, SHA512, SHA256, SHA1
Komprimierung: BZIP2, ZLIB, nicht komprimiert
Eigenschaften: MDC, Keyserver no-modify

Gewünschte Algorithmen setzen:

gpg> setpref TWOFISH AES256 AES192 RIPEMD160 SHA512 SHA256 BZIP2 ZLIB
gpg> q
Änderungen speichern? (j/N) j

Der Schlüssel arbeitet ab sofort nur noch mit den festgelegten Verfahren. Kommunikationspartner, deren GPG-Installation keines dieser Verfahren unterstützt, fallen automatisch auf 3DES zurück.

Welchen Verfahren man letztlich vertraut, muss jeder für sich entscheiden.


Update 2025: Gehärtete gpg.conf für GnuPG 2.4

Die Schlüssel-Präferenzen oben sind der erste Schritt. Der zweite ist die lokale gpg.conf. Sie bestimmt, welche Algorithmen GnuPG überhaupt anbietet, wie die Passphrase gehärtet wird und wo nach Schlüsseln gesucht wird. Meine aktuelle Konfiguration für GnuPG 2.4 unter Linux:

# ~/.gnupg/gpg.conf — Hardened Config für GnuPG 2.4

# Ausgabe: lange Key-IDs und Fingerprints anzeigen
keyid-format 0xlong
with-fingerprint
utf8-strings

# Schlüssel automatisch suchen: erst WKD, dann DANE, dann Keyserver
auto-key-retrieve
auto-key-locate wkd,dane,local,keyserver
keyserver hkps://keys.openpgp.org

# Starke Defaults
cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512

# KDF-Härtung: S2K mit 65 Mio. Iterationen
s2k-mode 3
s2k-digest-algo SHA512
s2k-cipher-algo AES256
s2k-count 65011712

# Legacy-Algorithmen komplett deaktivieren
disable-cipher-algo 3DES
disable-cipher-algo IDEA
disable-cipher-algo CAST5
disable-cipher-algo BLOWFISH
disable-cipher-algo TWOFISH

# Metadata minimieren
no-comments
no-emit-version
export-options export-minimal

# Trust-Modell: TOFU kombiniert mit Web of Trust
trust-model tofu+pgp

# Bevorzugte Algorithmen (lokal)
personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
weak-digest SHA1
force-ocb

# Default-Key (Ed25519)
default-key 0x5F279C362EEAB216

Was sich geändert hat

Ed25519 statt RSA. Mein aktueller Schlüssel ist ein Ed25519. Kürzere Schlüssel, schnellere Operationen, gleiche Sicherheit. RSA 4096 funktioniert weiterhin, aber für neue Schlüssel gibt es keinen Grund mehr dafür.

Legacy-Algorithmen deaktiviert. 3DES, IDEA, CAST5, Blowfish und Twofish sind per disable-cipher-algo komplett gesperrt. GnuPG bietet sie nicht mehr an und akzeptiert sie nicht. Das ist aggressiver als setpref, weil es auch eingehende Nachrichten betrifft. Wer damit Probleme bekommt, hat ein Gegenüber mit sehr veraltetem Setup.

S2K-Hardening. Die s2k-count Direktive bestimmt, wie oft die Passphrase bei symmetrischer Verschlüsselung gehasht wird. 65 Millionen Iterationen machen Brute-Force auf die Passphrase deutlich teurer. Der Wert ist der Maximalwert, den GnuPG akzeptiert.

OCB statt MDC. force-ocb erzwingt Authenticated Encryption (OCB) statt des älteren MDC (Modification Detection Code). OCB erkennt Manipulationen kryptographisch, nicht nur per Hash.

TOFU+PGP. trust-model tofu+pgp kombiniert das klassische Web of Trust mit Trust on First Use. Beim ersten Kontakt wird der Schlüssel akzeptiert, danach warnt GnuPG bei Änderungen. Pragmatischer als reines WoT, das in der Praxis kaum jemand pflegt.

WKD und DANE. auto-key-locate wkd,dane,local,keyserver sucht Schlüssel zuerst per Web Key Directory und DANE, bevor der Keyserver gefragt wird. WKD liefert den Schlüssel direkt von der Domain des Empfängers. keys.openpgp.org als Keyserver statt der alten SKS-Pools, weil dort E-Mail-Adressen nur nach Bestätigung veröffentlicht werden.

Metadata minimieren. no-comments, no-emit-version und export-minimal sorgen dafür, dass verschlüsselte Nachrichten und exportierte Schlüssel keine unnötigen Informationen enthalten. Kein Kommentarfeld, keine GnuPG-Versionsnummer, keine überflüssigen Signaturen beim Export.

Fragen? Einfach melden.

Linux LUKS: Falsche Tastatur bei der Passphrase-Abfrage

Festplattenverschlüsselung mit LUKS ist eine feine Sache. Bis man beim Booten sein Passphrase eingibt, es dreimal falsch ist und sich fragt ob man den Verstand verloren hat. Man hat sein Passphrase mit deutscher Tastatur eingerichtet, aber beim Booten lädt Linux die Keymap erst nach der LUKS-Abfrage. Also tippt man auf einer englischen Tastatur und wundert sich, warum Y und Z vertauscht sind und die Umlaute fehlen.

Ich hab mich davon auch schon verarschen lassen. Nicht nur einmal. Die Lösung ist je nach Distribution unterschiedlich, aber das Grundprinzip ist immer dasselbe: Man muss dem initramfs beibringen, die richtige Keymap zu laden bevor die Passphrase-Abfrage kommt.

Lösung: vconsole.conf + initramfs

Auf systemd-basierten Distributionen (Debian, Ubuntu, Fedora, Arch) setzt man die Keymap in /etc/vconsole.conf:

# /etc/vconsole.conf
KEYMAP=de-latin1

Danach das initramfs neu bauen, damit die Keymap beim Booten verfügbar ist:

# Debian/Ubuntu
update-initramfs -u

# Fedora/RHEL
dracut --force

# Arch
mkinitcpio -P

Nach dem nächsten Reboot wird die deutsche Keymap vor der LUKS-Abfrage geladen.

Alternative: GRUB Kernel-Parameter

Auf Gentoo-basierten Distributionen (Gentoo, Funtoo, das inzwischen eingestellte Sabayon) kann man die Keymap über Kernel-Parameter in GRUB setzen:

# /etc/default/grub
GRUB_CMDLINE_LINUX="... dokeymap keymap=de"

Nach grub-mkconfig -o /boot/grub/grub.cfg greift das beim nächsten Boot. dokeymap weist das initramfs an, die Keymap sofort zu wechseln.

Wenn es zu spät ist

Wer sein Passphrase bereits mit der falschen Keymap eingegeben hat und nicht mehr reinkommt: Das Passphrase auf einer US-Tastatur tippen. Also mental die deutschen Sonderzeichen auf ihre US-Positionen mappen. Z und Y sind vertauscht, ö ist ; und ä ist ‚, Bindestrich liegt woanders. Oder man schließt eine externe USB-Tastatur an und stellt sie auf US. Sobald man drin ist, die Keymap wie oben beschrieben fixen.

Fragen? Einfach melden.

StartSSL Identiy Validation Class 2

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und eingestellt. Kostenlose Zertifikate gibt es bei Let’s Encrypt.

Na wunderbar, mein Class 2 x.509 S/MIME Zertifikat läuft in kürze aus. Die Class 2 Validation ist auch ausgelaufen, also muss ich wohl was tun, hm?


Schnell alles bei StartSSL angeschoben und auf den bekannten Anruf irgendwo aus Israel warten… Es klingelte auch aber aus 001 213-341. Die Landesvorwahl ist USA und mein Android meint der Rest wäre etwas aus Los Angeles, CA! Das hat mich etwas überrascht; whatever. Wie gewohnt war das Gespräch schnell erledigt. Wobei die Dame am anderen Ende der Leitung extrem schlecht zu verstehen war. Nun warte ich also auf die Bestätigung meiner Class 2 Zertifizierung.

 


 

*UPDATE*

Na wunderbar:

### Schnipp ###
To Sebastian Van De Meer,

This electronic mail message was created by StartCom’s Administration Personnel:

Congratulations! Your Class 2 Identity Validation has been confirmed and approved. You are eligible for certificates at Class 2 level until 2014-05-01.
Additionally you have been awarded with StartSSL™ Web-of-Trust Notary status due to your fulfilling of all requirements. Well done!

Best Regards
### Schnapp ###

Dann kann ich ja gleich mal von diesem Zertifikat:

Seriennummer: 13:27
SHA1-Fingerprint: 28:AE:4C:96:51:75:EB:18:03:F9:9E:E3:7A:ED:C7:EA:13:8B:44:99

Zu diesem Zertifikat wechseln:

Seriennummer: 33:97
SHA1-Fingerprint: 7F:8B:92:19:FF:07:BF:EB:8E:E0:18:D4:98:B8:48:DF:E3:0E:4A:85

 

 

Unix / Linux Openssl Zertifikat pem konvertieren zu Microsoft Windows pfx

Man man man… Da bittet ein Kollege um ein Zertifikat, ich schraube das schnell zusammen und schiebe es im als .PEM – Base64-kodiertes Zertifikat, umschlossen von „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ zu.

Nun versucht dieser das Zertifikat auf seinem Windows Server zu importieren. Klappt aber so einfach nicht. Microsoft hätte nämlich gerne das Zertifikat als .PFX (.P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten.) Macht ja auch Sinn wenn es eh in einer Zertifikatsverwaltung liegt und dass ganze Kennwortgeschützt ist. So ist es etwas sicherer, wenn die Datei mal jemanden in die Hände fällt, der es nicht haben soll!

Wie also nun aus PEM ein PFX machen? Openssl hilft:

# openssl pkcs12 -export -out telefon.de.pfx -inkey telefon.de.key -in telefon.de.crt -certfile CACert.crt

telefon.de.key sowie telefon.de.crt sollten wir beim einfachen erstellen des Zertifikates per Openssl ja bereits haben. CACert.crt ist einfach der Zertifikat der CA, mit welchem unsere CSR unterschrieben wurde. Noch Fragen?

Siehe auch: Elliptic Curve Zertifikate mit OpenSSL

Fragen? Einfach melden.

GPG-Schlüssel per PKA im DNS veröffentlichen

Hinweis: PKA (Public Key Association) wird von GnuPG seit Version 2.1 (2014) nicht mehr unterstützt. Der Nachfolger ist der OPENPGPKEY Resource Record, der den kompletten Schlüssel direkt im DNS speichert. Dieser Beitrag beschreibt das ältere PKA-Verfahren — historisch interessant, aber für neue Setups nicht mehr empfehlenswert.


Die Idee hinter PKA

GnuPG konnte über DNS nach GPG-Schlüsseln fragen. Der Vorteil: Ich muss meinen öffentlichen Schlüssel nicht auf Keyservern verteilen, sondern veröffentliche ihn über meinen eigenen DNS-Server. Ist die Zone per DNSSEC geschützt, kann der Schlüssel nicht gefälscht werden — deutlich vertrauenswürdiger als Keyserver, auf denen jeder beliebige Schlüssel hochladen kann.

PKA funktioniert mit einem TXT-Record, der den Fingerprint des Schlüssels und eine URL zum Download enthält. GnuPG prüft den Fingerprint gegen den heruntergeladenen Schlüssel — stimmt beides überein, wird der Schlüssel importiert.

Schlüssel exportieren

Zuerst den öffentlichen Schlüssel exportieren und auf dem Webserver ablegen:

gpg --list-keys --fingerprint kernel-error@kernel-error.com
gpg --export --armor 0F9874D8 > kernel-error.asc

Die exportierte Datei muss per HTTP erreichbar sein — HTTPS ist nicht zwingend nötig, da der Schlüssel am Ende gegen den Fingerprint aus dem DNS geprüft wird.

PKA-Record erstellen

Der PKA-Record ist ein TXT-Record unter localpart._pka.domain. Er enthält den Fingerprint und die URL zum Schlüssel:

kernel-error._pka.kernel-error.com. IN TXT "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Aufbau: Das @ in der E-Mail-Adresse wird durch ._pka. ersetzt. Der Record enthält die PKA-Version (v=pka1), den vollständigen Fingerprint (fpr=...) und die Download-URL (uri=...). Für jede E-Mail-Adresse, unter der man erreichbar ist, braucht man einen eigenen Record — auch über verschiedene Zonen hinweg.

Prüfen

Mit dig testen, ob der Record im DNS angekommen ist:

dig +short kernel-error._pka.kernel-error.com TXT
"v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

GnuPG (bis Version 2.0) konnte den Schlüssel dann automatisch finden und importieren:

echo "test" | gpg --auto-key-locate pka --keyring /tmp/test.gpg \
  --encrypt --armor -r kernel-error@kernel-error.com

GnuPG fragt den PKA-Record ab, lädt den Schlüssel von der angegebenen URL herunter, prüft den Fingerprint und importiert den Schlüssel in den Keyring.

Warum OPENPGPKEY besser ist

PKA hatte zwei Schwächen: Der Schlüssel lag nicht im DNS selbst, sondern musste per HTTP heruntergeladen werden — ein zusätzlicher Angriffsvektor. Und der TXT-Record war auf 255 Bytes pro String begrenzt, was bei langen URLs und Fingerprints knapp wurde.

Der OPENPGPKEY Resource Record (RFC 7929) löst beides: Der komplette Schlüssel steckt direkt im DNS, kein HTTP-Download nötig. Mit DNSSEC ist die gesamte Kette vom DNS-Lookup bis zum Schlüssel kryptographisch abgesichert.

Siehe auch: OPENPGPKEY im DNS

Fragen? Einfach melden.

Evolution merkt sich die Einstellungen der Zertifizierungsstellen nicht

Ich nutze Evolution als E-Mail Client. In den Zertifikatseinstellungen habe ich unter Zertifizierungsstellen auch eine ganze Latte von CAs. Ich kann auch welche hinzufügen und entfernen alles kein Problem.

Will ich aber deren Einstellung bearbeiten, sprich für welche Dinge ich dieser CA vertrauen möchte bleiben diese Einstellungen nur immer für die aktuelle Sitzung gespeichert. Schließe und Starte ich Evolution wieder sind die Einstellungen alles wieder weg 🙁 Das ist doof!

Wer sucht, der findet einen Workaround……..

Das Problem ist wohl dass Evolution aus irgendwelchen Gründen die cert9.db / key4.db unter ~/.pki/nssdb nicht updatet.

So kann ich mir anschauen was bei mir eingetragen ist:

$ certutil -L -d sql:/home/kernel/.pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

StartCom Ltd. ID von Sebastian Van De Meer                   u,u,u
StartCom Class 2 Primary Intermediate Client CA - StartCom Ltd. ,,   
CA Cert Signing Authority - Root CA                          ,,   
CAcert Class 3 Root - Root CA                                ,,   
StartCom Class 1 Primary Intermediate Client CA - StartCom Ltd. ,,   
StartCom Certification Authority - StartCom Ltd.             ,,   
StartCom Ltd.                                                ,,   
StartCom Certification Authority                             ,,   
......

Und so verpasse ich den einzelnen Zertifikaten die passenden „Verwendungsmöglichkeiten“:

$ certutil -M  -n "CA Cert Signing Authority - Root CA"  -t "TCu,Cu,TCuw" -d sql:/home/kernel/.pki/nssdb/

Am Ende schaut es nun so aus (ich mache mir dann noch mal nen Kopf ob es so auch sinnig ist):

$ certutil -L -d sql:/home/kernel/.pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

StartCom Ltd. ID von Sebastian Van De Meer                   u,u,u
StartCom Class 2 Primary Intermediate Client CA - StartCom Ltd. CT,C,C
CA Cert Signing Authority - Root CA                          CT,C,C
CAcert Class 3 Root - Root CA                                CT,C,C
StartCom Class 1 Primary Intermediate Client CA - StartCom Ltd. CT,C,C
StartCom Certification Authority - StartCom Ltd.             C,C,C
StartCom Ltd.                                                C,C, 
StartCom Certification Authority                             C,C,C
......

Auf meine Openindiana Kiste musste ich dafür noch folgendes Paket installieren:

system/mozilla-nss

Und wegen des Bugs #1739 certutil with incomplete runpath musste ich noch folgenden Workaround dafür einwerfen:

$ elfedit -e 'dyn:runpath $ORIGIN/../lib:/usr/lib/mps' /usr/sfw/bin/certutil

Jetzt macht zwar Evolution nicht die Arbeit aber mein Wunsch ist erfüllt. Ob ich da mal nen Bug bei den Jungs aufmache?

So long…

Siehe auch: S/MIME per DNS mit SMIMEA

Fragen? Einfach melden.

StartSSL

Veraltet: StartSSL/StartCom wurde 2017 von allen Browsern als nicht mehr vertrauenswürdig eingestuft und hat den Betrieb eingestellt. Für kostenlose Zertifikate nimmt man heute Let’s Encrypt.

StartCom ist ein Unternehmen, das Software herstellt und als Zertifizierungsstelle digitale Zertifikate ausstellt. Seit Februar 2005 ist das Unternehmen als Zertifizierungsstelle tätig. Das bekannteste Produkt ist das kostenlose Class 1 X.509 SSL-Zertifikat „StartSSL Free“, das sowohl für Webserver (SSL/TLS) als auch für die E-Mail-Verschlüsselung (S/MIME) eingesetzt werden kann. Außerdem werden Class 2 Zertifikate und Extended-Validation-SSL-Zertifikate ausgestellt, für die eine kostenpflichtige Validierung Voraussetzung ist. StartCom-Zertifikate werden von allen modernen Browsern akzeptiert: Mozilla Firefox unterstützt sie schon ab Version 2.0, Opera seit Juli 2010, Apple Mac OS X ab Version 10.5 (Leopard) und Microsoft Windows seit September 2009; Apple Safari, Internet Explorer und Google Chrome greifen auf den Zertifikatspeicher des Betriebssystems zurück.

Das kostenlose Class1 Zertifikat stellt nur sicher das der angegebene Domainname existiert und anscheinend dem Halter des StartCom Accounts gehört. Aus diesem Grund findet sich natürlich auch nur der Domainname im Zertifikat. Wer seinen Namen auch noch im Zertifikat hinterlegen möchte kann dieses denn noch auf einem kostenlosen Weg schaffen. Ähnlich CAcert setzt StartCom auf das Prinzip des Web of Trust (wot). Es gibt bei StartCom ehrenamtliche Notare. Jeder Inhaber eines StartCom Accounts kann sich von diesen verifizieren lassen. Dazu findet sich im Webinterface des eigenen Accounts auf der Seite unter StartSSL WoT ==> WoT Netzwerk der Punkt Notarsucher. Hier findet sich über die Eingabe des eigenen Wohnortes oder halt der nächsten größeren Stadt schnell ein solcher Notar.

Wurde man von mindestens zwei dieser Notare bestätigt, kann man seinen Namen mit ins Zertifikat aufnehmen.

Eine solche Bestätigung findet immer über ein persönliches Treffen mit dem Notar statt. Bei diesem Treffen prüft der Notar anhand von zwei amtlichen Lichtbildausweisen ob der Name im Account mit dem auf den Ausweisen identisch ist.

Da die Root-Zertifikate dieser Zertifizierungsstelle bereits in den meisten großen Browsern und Betriebssystemen enthalten sind, kommt es bei diesen Zertifikaten (anders als bei z.B. CAcert.org) nicht zu „Fehlermeldunge“ bzw. Warnmeldungen im Zusammenhang mit den Zertifikaten. Vor allem dieser Umstand und natürlich da es kostenneutral ist, würde ich StartCom x.509 Zertifikate als einen optimalen Einstieg in diesen Themenbereich nennen können. Wer am Ende mehr will, wie eine Class 2 Zertifizierung oder bis hin zum Class 3 Zertifikat für Unternehmen, kann dieses schnell und günstig weiterführen. Wem das Class 1 Zertifikat ausreicht, dem stehen direkt nach der erfolgreichen Anmeldung schon fast alle Möglichkeiten der E-Mail Signatur / Verschlüsselung sowie SSL/TLS Verschlüsselte Serververbindungen offen.

Ich selbst bin bei StartSSL Notar und wie bei GPG / PGP oder CAcert.org bestätige ich auch hier gerne Identitäten auf Anfrage.

DNSSEC einrichten: Zonen signieren mit BIND

DNSSEC (Domain Name System Security Extensions) schützt DNS-Antworten vor Fälschung. Ein anfragender Resolver kann damit prüfen, ob die gelieferten Zonendaten tatsächlich vom autorisierten Nameserver stammen und unterwegs nicht verändert wurden. DNSSEC wurde als Mittel gegen Cache Poisoning entwickelt — Serverauthentifizierung findet nicht statt.

Die Vertrauenskette

Was mich beim ersten Lesen zu DNSSEC durcheinandergebracht hat, war das Umherwerfen mit Begriffen: KSK, ZSK, DNSKEY, RRSIG, DS. Im Grunde ist es einfach:

Der KSK (Key Signing Key) hat eine Aufgabe: den ZSK unterschreiben. Der KSK wird als DS-Record in der übergeordneten Zone hinterlegt. Der ZSK (Zone Signing Key) hat auch nur eine Aufgabe: die eigentlichen Zonendaten unterschreiben.

Es beginnt bei der Root-Zone. Die Root-Server wissen, welche Nameserver für die TLDs zuständig sind. Die TLD-Server wissen, welche Nameserver für die einzelnen Domains zuständig sind. Jede Ebene signiert ihre Zone und veröffentlicht den DS-Record der Ebene darunter. So entsteht eine durchgehende Kette vom Root-KSK bis zu meiner Zone.

Will ein Angreifer dafür sorgen, dass www.kernel-error.org auf seinen Server zeigt, hat er zwei Möglichkeiten:

  1. Er antwortet auf die Delegation-Anfrage mit seinem eigenen Nameserver.
  2. Er antwortet mit gefälschter Absenderadresse schneller als der echte Server.

Mit DNSSEC kann der Resolver beide Angriffe erkennen — die gefälschte Antwort hat keine gültige Signatur.

Schematische Darstellung der DNSSEC-Vertrauenskette: Root-KSK signiert TLD, TLD signiert Domain.

DNSSEC in BIND aktivieren

Auf dem autoritativen Nameserver muss DNSSEC-Validierung aktiv sein. In modernen BIND-Versionen (ab 9.16) reicht im options-Block:

options {
    dnssec-validation auto;
};

auto bedeutet, dass BIND den eingebauten Root-Trust-Anchor nutzt und diesen bei KSK-Rollovers automatisch aktualisiert (RFC 5011). Der alte dnssec-enable yes wurde in BIND 9.18 entfernt — DNSSEC ist seitdem immer aktiv.

Zone signieren — der moderne Weg

Seit BIND 9.16 gibt es dnssec-policy. Damit übernimmt BIND die Schlüsselerzeugung, das Signieren und den Key-Rollover vollautomatisch:

zone "kernel-error.org" {
    type primary;
    file "kernel-error.org";
    dnssec-policy default;
    inline-signing yes;
};

Die default-Policy verwendet ECDSAP256SHA256 (Algorithmus 13) — schneller und sicherer als das früher übliche NSEC3RSASHA1 mit 4096-Bit-Schlüsseln. inline-signing yes bedeutet: BIND signiert die Zone im Speicher, die Zonendatei auf der Platte bleibt unsigniert und lässt sich wie gewohnt bearbeiten.

Zone manuell signieren

Wer mehr Kontrolle will oder eine ältere BIND-Version hat, kann die Schlüssel von Hand erzeugen. KSK erstellen:

$ dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE kernel-error.org
Kkernel-error.org.+013+12345

ZSK erstellen:

$ dnssec-keygen -a ECDSAP256SHA256 -n ZONE kernel-error.org
Kkernel-error.org.+013+67890

Die öffentlichen Teile (*.key) in die Zonendatei einbinden und signieren:

$ cat Kkernel-error.org.+013+*.key >> kernel-error.org

$ dnssec-signzone -S -K /pfad/zu/keys -o kernel-error.org kernel-error.org
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone signing complete:
Algorithm: ECDSAP256SHA256: ZSKs: 1, KSKs: 1 active, 0 stand-by
kernel-error.org.signed

Dann BIND anweisen, die signierte Zonendatei zu laden. Nach jeder Änderung an der Zone muss neu signiert werden — oder man nutzt inline-signing, dann entfällt das.

DS-Record beim Registrar einreichen

Der öffentliche KSK muss als DS-Record in der übergeordneten Zone landen. Bei der DENIC (.de) und den meisten TLD-Registries gibt es dafür ein Webinterface beim Registrar. Man schickt den öffentlichen KSK hin, der Registrar erstellt daraus einen DS-Record und veröffentlicht ihn neben den NS-Records.

Ob der DS-Record gesetzt ist, lässt sich prüfen, indem man die TLD-Nameserver direkt fragt:

$ dig +short kernel-error.org DS @a0.org.afilias-nst.info
12345 13 2 A1B2C3D4...

Prüfen ob alles funktioniert

Mit dig +dnssec eine signierte Domain abfragen. Das ad-Flag (Authenticated Data) in der Antwort zeigt, dass die DNSSEC-Validierung erfolgreich war:

$ dig +dnssec kernel-error.org @8.8.8.8
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Grafisch lässt sich die gesamte Vertrauenskette mit DNSviz darstellen — einfach die eigene Domain einsetzen:

Stolpersteine

DNSSEC-Signaturen machen DNS-Antworten deutlich größer als die 512 Bytes, die klassisches DNS über UDP erlaubt. EDNS (RFC 6891) hebt dieses Limit auf. Das ist seit 1999 spezifiziert, aber manche Firewalls und Billig-Router haben damit immer noch Probleme — sie filtern große UDP-Pakete oder EDNS-Optionen.

Wichtig: Gehen die Schlüssel verloren oder die signierte Zonendatei brennt ab, hat man ein Problem. Vor jeder großen Änderung (Key-Rollover, Algorithmus-Wechsel) immer die längste TTL der Zone abwarten. Sonst sind gecachte Antworten mit der alten Signatur noch gültig, während die neue Signatur schon aktiv ist — die Zone wird temporär nicht validierbar.

Meinen „analogen“ DNSSEC-Masterplan dazu habe ich mir damals aufgezeichnet:

Handgezeichneter DNSSEC-Masterplan: Reihenfolge fuer Key-Rollover und Zonenuebergaenge mit TTL-Wartezeiten.

Was man auf DNSSEC aufbauen kann

Wenn die Zone signiert ist, lassen sich darüber weitere Sicherheitsmechanismen verteilen:

Wer einen DNSSEC-validierenden Resolver sucht — dns.kernel-error.de bietet DNS over TLS und DNS over HTTPS mit DNSSEC-Validierung.


Chronik

Dieser Beitrag wurde 2010 veröffentlicht und dokumentiert meine DNSSEC-Einführung über mehrere Jahre:

  • November 2010 — Erste Signierung von kernel-error.org (NSEC3RSASHA1, 4096 Bit).
  • Februar 2011 — DS-Record für kernel-error.org endlich in der .org-Zone veröffentlicht. DENIC kündigt Signierung der .de-TLD an.
  • Februar 2011 — kernel-error.de signiert, über DENIC-Testbed validierbar.
  • Juni 2011 — DENIC signiert .de offiziell, DS-Records in der Root-Zone.
  • Februar 2012 — kernel-error.com ebenfalls signiert. Alle drei Domains komplett.
  • Mai 2012 — GPG-Keys und SSHFP-Records im DNS hinterlegt.
  • August 2013 — DANE/TLSA-Records für alle TLS-Dienste eingerichtet.
  • 2024 — Algorithmus-Wechsel auf ECDSAP256SHA256 (Algorithmus 13). Anleitung oben entsprechend aktualisiert.

Siehe auch: DNSSEC und DANE

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑