-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: DNSSEC (Seite 3 von 4)

IP Reverse Map Delegation: Einrichtung und Fehlerbehebung

17. Oktober 2014 / / Keine Kommentare
IP-Reverse-Map-Delegation nach RFC 2317 mit Provider-Zone, Kunden-Subzone, CNAME-Verweisen, PTR-Antwort und Troubleshooting-Hinweisen.

Reverse Map Delegation nach RFC 2317 klingt komplizierter als es ist. Es löst ein konkretes Problem: Wer ein kleines IP-Netz hat (kleiner als /24), kann normalerweise keine eigene PTR-Zone betreiben. Mit Reverse Map Delegation geht es doch.

Warum man es braucht

In der guten alten Zeit bekam man ein /24 (256 Adressen). Da legt man einfach eine Zone 3.2.1.in-addr.arpa. an und fertig. Heute bekommt man, wenn überhaupt, ein /29 (8 Adressen). Und da liegt das Problem: DNS-Zonen werden am Punkt getrennt. Bei einem /24 passt das, bei einem /29 gibt es keinen Punkt an dem man die Zone aufteilen kann.

Der Provider behält also die /24-Zone und richtet für das kleine Subnetz CNAMEs ein, die auf eine „Sub-Zone“ des Kunden zeigen. Der Kunde kann dann seine PTR-Records selbst verwalten.

Die Provider-Seite

In der /24-Zone des Providers wird für das Subnetz 1.2.3.0/29 eine Delegation eingerichtet. Jede IP-Adresse bekommt einen CNAME in die Sub-Zone des Kunden:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.kernel-error.de.
         IN NS  ns2.kernel-error.org.

; Delegation für 1.2.3.0/29 an den Kunden
0/29     IN NS    ns1.vandemeer.de.
0/29     IN NS    ns2.vandemeer.de.
0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Die Kunden-Seite

Der Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.vandemeer.de.
         IN NS  ns2.vandemeer.de.

0        IN PTR netzadresse.vandemeer.de.
1        IN PTR router.vandemeer.de.
2        IN PTR mailin.vandemeer.de.
3        IN PTR imap.vandemeer.de.
4        IN PTR webserver.vandemeer.de.
5        IN PTR frei.vandemeer.de.
6        IN PTR frei.vandemeer.de.
7        IN PTR broadcastadresse.vandemeer.de.

Ergebnis

Eine Reverse-Lookup-Abfrage für 1.2.3.4 läuft jetzt über den CNAME zum DNS des Kunden und liefert den gewünschten PTR-Record:

dig -x 1.2.3.4 +short
4.0/29.3.2.1.in-addr.arpa.
webserver.vandemeer.de.

Probleme

Wäre ja zu schön, wenn es keine gäbe.

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein, außer in genau diesem Fall. Das RFC ist von 1998, aber es hat sich nicht überall herumgesprochen. Man muss seinem Gegenüber gelegentlich RFC 2317 erklären, bevor die Diskussion weitergeht.

Außerdem macht Postfix Ärger, wenn man reject_unknown_client in den smtpd_restrictions hat. Diese Prüfung erwartet, dass PTR und A/AAAA-Record zueinander passen. Bei Reverse Map Delegation tun sie das nicht, weil der CNAME dazwischen steht:

450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]

Wer einen größeren Mailserver betreibt, sollte auf der Mail-IP kein Reverse Map Delegation einsetzen, sondern den PTR direkt beim Provider setzen lassen. Spart Arbeit und Ärger.

Fragen? Einfach melden.

mailgraph Graphen um DANE erweitern

9. August 2014 / / Keine Kommentare

Wie sich die grafische Logfile Auswertung für, unter anderem, Postfix um Dinge wie SPF, DKIM und DMARC erweitern lässt, habe ich ja bereits vor kurzem hier gezeigt: mailgraph Graphen um SPF, DMARC und DKIM erweitern

Seit ein paar Monaten ist an meinem Mailserver DANE aktiviert, sprich es lassen sich die TLSA RECORDS für die Zertifikate am Postfix gegen einen DNSSEC gesicherten DNS Server abgleichen.

In diesem Zuge habe ich selbstverständlich die ausgehende Prüfung am Postfix aktiviert. Mein Postfix nutzt nun also auch DANE um die Verbindung zu anderen Mailserver zu prüfen. Dabei gibt es im Grunde nur vier mögliche Ergebnisse einer Prüfung der TLS Verbindung:

Verified

Der bisher seltenste aber beste Fall. Denn die ausgehende Verbindung zum anderen Server ist per DANE gesichert. Das Zertifikat ist also nicht nur gültig sondern konnte auch mit den TLSA-RECORDS abgeglichen werden.

Trusted

Der OK Fall… Das Zertifikat ist gültig.

Anonymous

Na ja… Es gibt ein Zertifikat und dieses ist passend zum Hostname, es konnte aber keine Vertrauenskette gebildet werden.

Untrusted

Schlecht! Es gibt zwar ein Zertifikat und somit auch eine verschlüsselte Verbindung, denn noch stimmt etwas mit dem Zertifikat nicht. Es ist abgelaufen, passt nicht zum Hostname oder ähnliches.

Im Logfile findet es sich wie folgt:

Aug  3 18:34:08 servername postfix/smtp[1234]: Verified TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  9 12:07:28 servername postfix/smtp[1234]: Trusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  8 22:15:34 servername postfix/smtp[1234]: Anonymous TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Aug  7 21:48:48 servername postfix/smtp[1234]: Untrusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)

Was mich nun interessiert, ist die Tendenz der einzelnen Prüfungen. Wie sicher ist die Kommunikation zu anderen Mailservern wirklich, rein bezogen auf die Vertrauenswürdigkeit der eingesetzten Zertifikate. Eine schnelle Übersicht soll mir hier wieder der mailgraph liefern.

Den Mailgraph habe ich also, wie mit SPF, DKIM und DMARC ebenfalls, erweitert. Das nötige Patchset gibt es natürlich wieder unten. Dieses Mal habe ich darauf geachtet für die TLS Auswertung ein eigenes File für die RRD-Daten anzulegen. So kann ein bestehender Mailgraph einfach erweitert werden, ohne die vorhandenen Daten zu verlieren.

Heraus kommt am Ende dieser Graph.

Für interessiere finden sich die beiden nötigen Patchfiles hier:

/usr/sbin/mailgrapht

/usr/lib/cgi-bin/mailgraph.cgi

Viel Spaß! Bei Fragen, fragen.

Fragen? Einfach melden.

DNSSEC-fähiger Registrar

18. Juni 2014 / / Keine Kommentare

In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registrar ich zusammenarbeite. Vor allem im Hinblick auf DNSSEC und die DS-Records, die man beim Registrar hinterlegen muss.

Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Damals habe ich dort gerne mit Herrn Metz zusammengearbeitet. Es war immer jemand erreichbar, und auch etwas ungewöhnliche Dinge ließen sich schnell umsetzen. Das Webinterface konnte 2014 noch keine DS-Records entgegennehmen, der Weg per E-Mail funktionierte aber binnen Minuten.

Es kommt selten vor, dass ich hier Werbung für ein Unternehmen mache — dieses hatte es damals verdient.

Mehr zu DNSSEC und BIND gibt es im DNSSEC-HowTo. Fragen? Einfach melden.

TLSA- und DANE-Records manuell prüfen: Schritt für Schritt mit OpenSSL

19. Mai 2014 / / Keine Kommentare

Es gibt inzwischen viele Webtools die TLSA-Records prüfen. Aber wer es einmal von Hand gemacht hat, versteht was dabei passiert. Der Ablauf ist immer gleich: Zertifikat vom Server holen, Hash berechnen, mit dem DNS-Record vergleichen.

Zertifikat holen

Verbindung zum Mailserver aufbauen und das Zertifikat per STARTTLS abholen:

openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 \
  -servername smtp.kernel-error.de 2>/dev/null | \
  openssl x509 -outform PEM > /tmp/server.crt

Das Zertifikat liegt jetzt in /tmp/server.crt.

Hash berechnen

Welchen Hash man berechnen muss, hängt vom TLSA-Record ab. Die drei Felder im Record bestimmen das:

Usage0 = CA, 1 = End-Entity (Kette muss gültig sein), 2 = Trust Anchor, 3 = End-Entity (keine Kettenprüfung)
Selector0 = ganzes Zertifikat, 1 = nur Public Key (SPKI)
Matching Type0 = exakter Vergleich, 1 = SHA-256, 2 = SHA-512

Am häufigsten sieht man 3 1 1 (End-Entity, nur Public Key, SHA-256) oder 3 0 1 (End-Entity, ganzes Zertifikat, SHA-256). Zuerst den TLSA-Record aus dem DNS holen um zu sehen was erwartet wird:

dig _25._tcp.smtp.kernel-error.de TLSA +short

Dann den passenden Hash berechnen. Bei Selector 0 (ganzes Zertifikat) und Matching Type 1 (SHA-256):

# Selector 0 (Full Certificate), SHA-256
openssl x509 -in /tmp/server.crt -outform DER | openssl sha256
# Ausgabe: SHA2-256(stdin)= 94c8e1bd...

Bei Selector 1 (nur SPKI, Public Key) und SHA-256:

# Selector 1 (SPKI), SHA-256
openssl x509 -in /tmp/server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | openssl sha256

Den berechneten Hash mit dem Wert aus dem TLSA-Record vergleichen. Stimmen sie überein, ist der Record korrekt.

Schnelltest mit posttls-finger

Wer nicht alles von Hand machen will: posttls-finger (Teil von Postfix) prüft den kompletten DANE-Ablauf in einem Schritt:

posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de

In der Ausgabe steht am Ende entweder Verified TLS connection established (DANE-Prüfung bestanden) oder eine Fehlermeldung mit dem konkreten Problem. Das Tool löst die MX-Records auf, holt den TLSA-Record, baut die TLS-Verbindung auf und vergleicht alles automatisch.

Wer DANE für den eigenen Mailserver einrichten will, findet die Anleitung unter Postfix mit DANE und DNSSEC absichern. Die Grundlagen zu DANE und TLSA-Records erklärt der Beitrag DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern. Fragen? Einfach melden.

dnssec validator Browser Plugin

9. Mai 2014 / / Keine Kommentare

Veraltet: Das DNSSEC Validator Browser-Plugin wird nicht mehr gepflegt und ist in aktuellen Firefox-/Chrome-Versionen nicht mehr verfügbar. DNSSEC-Validierung sollte auf dem DNS-Resolver stattfinden, nicht im Browser.

Na schau mal einer an… Das Browser Plugin für den DNSSEC Validator kann nun auch DANE / TLSA und er zeigt es angenehm übersichtlich an.

https://www.dnssec-validator.cz/pages/download.html
Ist in jedem Fall noch mal einen Klick wert.

Perfect Forward Secrecy für Postfix und Dovecot konfigurieren

15. Februar 2014 / / Keine Kommentare

Perfect Forward Secrecy (PFS) sorgt dafür, dass jede TLS-Verbindung einen eigenen temporären Schlüssel verwendet. Selbst wenn jemand den privaten Schlüssel des Servers in die Hände bekommt, kann er damit früher aufgezeichnete Verbindungen nicht entschlüsseln. Für E-Mail ist das besonders relevant, weil Mailverkehr gern auf Vorrat mitgeschnitten wird.

PFS bekommt man durch ECDHE- oder DHE-Schlüsselaustausch. Moderne OpenSSL-Versionen und aktuelle Postfix/Dovecot-Releases machen das Richtige von Haus aus. Trotzdem lohnt sich ein Blick auf die Konfiguration, um sicherzustellen, dass keine veralteten Protokolle oder Cipher-Suiten aktiv sind.

Postfix

Die relevanten Einstellungen in der main.cf:

# Eingehend (smtpd)
smtpd_tls_security_level = may
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_mandatory_ciphers = medium

# Ausgehend (smtp)
smtp_tls_security_level = dane
smtp_tls_protocols = >=TLSv1.2
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_mandatory_ciphers = medium

# Cipher-Präferenz beim Server
tls_preempt_cipherlist = yes

>=TLSv1.2 schaltet TLS 1.0 und 1.1 ab. tls_preempt_cipherlist = yes lässt den Server die Cipher-Reihenfolge bestimmen, nicht den Client. Postfix sortiert AEAD-Ciphers (GCM, CHACHA20) automatisch nach vorn, PFS-Ciphers haben Vorrang. Die medium-Stufe schließt alles unterhalb von 128-Bit-Verschlüsselung aus.

Für den ausgehenden Versand ist smtp_tls_security_level = dane die beste Wahl. Damit prüft Postfix TLSA-Records per DANE. Gibt es keinen TLSA-Record, fällt Postfix auf opportunistisches TLS zurück. Wer zusätzlich MTA-STS auswertet, deckt auch Server ohne DNSSEC ab.

Dovecot

In /usr/local/etc/dovecot/conf.d/10-ssl.conf (FreeBSD) bzw. /etc/dovecot/conf.d/10-ssl.conf (Linux):

ssl = required
ssl_min_protocol = TLSv1.2
ssl_prefer_server_ciphers = yes
ssl_options = no_ticket

ssl = required erzwingt TLS für alle Verbindungen. ssl_min_protocol = TLSv1.2 schließt alte Protokolle aus. ssl_prefer_server_ciphers = yes gibt dem Server die Kontrolle über die Cipher-Wahl. no_ticket deaktiviert TLS Session Tickets, die PFS untergraben können wenn der Ticket-Key kompromittiert wird.

Eine explizite Cipher-Liste ist bei aktuellem OpenSSL nicht nötig. Die Defaults bevorzugen ECDHE mit AEAD. Wer es trotzdem einschränken will:

ssl_cipher_list = ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM:DHE+CHACHA20:!aNULL:!eNULL
ssl_cipher_suites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

ssl_cipher_list gilt für TLS 1.2, ssl_cipher_suites für TLS 1.3. Bei TLS 1.3 ist PFS immer aktiv, da gibt es keine Cipher-Suiten ohne Schlüsselaustausch mehr.

Testen

# Postfix (STARTTLS auf Port 25)
openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Postfix (Implicit TLS auf Port 465)
openssl s_client -connect smtp.kernel-error.de:465 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Dovecot (STARTTLS auf Port 143)
openssl s_client -starttls imap -connect imap.kernel-error.de:143 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Dovecot (Implicit TLS auf Port 993)
openssl s_client -connect imap.kernel-error.de:993 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

Entscheidend ist die Zeile Server Temp Key. Steht dort X25519, ECDH P-256 oder DH 2048, ist PFS aktiv. Mit OpenSSL 3.5+ und entsprechender Konfiguration sieht man dort auch X25519MLKEM768 für Post-Quantum-Schlüsselaustausch.

Siehe auch: Post-Quantum TLS für E-Mail

Fragen? Einfach melden.

Postfix mit DANE und DNSSEC absichern

28. Januar 2014 / / Keine Kommentare
Postfix-Mailserver mit DANE und DNSSEC, TLSA-Record-Prüfung, DNS als Vertrauensanker und verifizierter SMTP-TLS-Verbindung zwischen Mailservern.

Meine Domains sind schon lange per DNSSEC gesichert. Für den Webserver hatte ich auch schnell TLSA-Records veröffentlicht, damit die TLS-Verbindung per DANE abgesichert ist. Seit Postfix 2.11 beherrscht auch der MTA die Prüfung von TLSA-Records, damit lässt sich ausgehende E-Mail-Verschlüsselung kryptographisch verifizieren, ohne sich auf das CA-System verlassen zu müssen.

Postfix konfigurieren

Zwei Zeilen in der main.cf reichen, damit Postfix beim Versand TLSA-Records prüft:

postconf -e "smtp_dns_support_level = dnssec"
postconf -e "smtp_tls_security_level = dane"

smtp_dns_support_level = dnssec weist den SMTP-Client an, DNSSEC-validierte DNS-Antworten zu verlangen. smtp_tls_security_level = dane aktiviert die TLSA-Prüfung, Postfix sucht automatisch nach TLSA-Records für den Zielserver. Gibt es keinen TLSA-Record oder kein DNSSEC, fällt Postfix auf opportunistisches TLS zurück. Die Kommunikation mit Servern ohne DANE leidet also nicht. Details stehen in der Postfix DANE-Dokumentation.

TLSA-Record erstellen

Der TLSA-Record enthält einen Hash des TLS-Zertifikats (oder des Public Keys), den der Empfänger-Mailserver im DNS veröffentlicht. So erzeugt man den SHA-256-Hash des Public Keys aus dem Zertifikat:

openssl x509 -in postfix.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Den Hash trägt man als TLSA-Record in die DNS-Zone ein, für Port 25 (SMTP) und optional Port 465 (Implicit TLS):

_25._tcp.smtp.kernel-error.de.  3600 IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
_465._tcp.smtp.kernel-error.de. 3600 IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Die Felder 3 1 1 bedeuten: DANE-EE (End Entity, kein CA-Vertrauen nötig), SPKI (nur Public Key, nicht das ganze Zertifikat), SHA-256. Der TTL von 3600 Sekunden ist bewusst kurz, bei einem Zertifikatswechsel soll der alte Record schnell ablaufen. Mehr zum Aufbau von TLSA-Records steht in RFC 7672.

Testen

Mit posttls-finger (Teil von Postfix) lässt sich prüfen, ob die DANE-Verifikation funktioniert:

posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de

Die entscheidende Zeile in der Ausgabe:

Verified TLS connection established to smtp.kernel-error.de[...]:25:
  TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Verified statt Untrusted, der TLSA-Record stimmt mit dem Zertifikat überein, die Verbindung ist DANE-verifiziert. Im Postfix-Log sieht man denselben Unterschied:

smtp[3779]: Verified TLS connection established to mx02.example.de[...]:25
smtp[3779]: Untrusted TLS connection established to smtp2.example.de[...]:25

Verified = DANE-geprüft und in Ordnung. Untrusted = TLS aktiv, aber kein gültiger TLSA-Record vorhanden, die Verschlüsselung funktioniert trotzdem, nur ohne kryptographische Verifikation des Zertifikats.

Warum DANE besser ist als das CA-System

DANE verankert das Vertrauen im DNS statt bei Certificate Authorities. Der Domaininhaber veröffentlicht den Hash seines Zertifikats selbst, DNSSEC schützt den Record vor Manipulation. Keine CA kann ein falsches Zertifikat für die Domain ausstellen und damit die Verbindung aufbrechen. Das Ganze kostet nichts außer einem DNS-Record und funktioniert für jeden, der DNSSEC betreibt.

Zum Vergleich: Das damalige „E-Mail made in Germany“ (EmiG) setzte auf eine TÜV-Zertifizierung, die sich nur große Provider leisten konnten. Sicherheit nur für Unternehmen mit Budget, das ist das Gegenteil von dem, was ich unterstütze.

Update August 2014: Ich habe Mailgraph um DANE-Graphen erweitert, um den Anteil verifizierter Verbindungen zu visualisieren.

Siehe auch: TLSA/DANE-Records prüfen, TLSA- und DANE-Records manuell prüfen: Schritt für Schritt mit OpenSSL, Postfix und DANE: „Server certificate not verified“ debuggen, Postfix: Eingehende E-Mails ohne TLS ablehnen

Fragen? Einfach melden.

Version bei BIND nicht anzeigen lassen: Schritt-für-Schritt-Anleitung

26. November 2013 / / Keine Kommentare

Es gibt viele gute Gründe warum man die Version seines DNS Servers unkenntlich machen sollte. Viele Roboter und noch mehr Scriptkiddies suchen nach Versionen mit Sicherheitslöchern. Natürlich sollte man seine Version immer auf dem aktuellen Stand der Sicherheitsupdates halten… Denn noch kommt es vor dass man auch mal ein paar Tage auf einer „kaputten“ Version läuft. Dieses muss man ja nicht jedem unter die Nase reiben, hm?

Beim Bind ist es extrem einfach. Man reißt einfach mit dem Editor seiner Wahl die named.conf auf und wandert zum Options-Bereich. Dort ergänst man einfach die Option version:

options
{

[Zeugs und andere Optionen]
version "unknown";
[noch mehr Zeugs und andere Optionen]

};

Nun einfach Bind seine Konfiguration neu laden lassen:

$ rndc reconfig

Schon wird keine Version mehr angezeigt. Testen kann man alles wie immer mit dig:

$ dig -c CH -t txt version.bind +short @dns1.telekom.de
"SORRY"

Sorry finde ich gut liebe Telekom.

Bock auf ein kleines Spiel? Wer mir zuerst sagt auf welchem Schiff mein primärer DNS Server stehen müsste, der bekommt eine Dose Dr Pepper Cola geschenkt.

Update 26.11.2013 19:53

Glückwunsch Dome, du bekommst die Dose. Bekomme ich ein Foto wie alles ausschaut nachdem DHL das Paket (oder besser Maxibrief *grübel*) bei dir abgegeben hat? Ich löse aber mal nicht, dann können die anderen noch mitspielen!

Siehe auch: DNSSEC einrichten

Fragen? Einfach melden.

DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern

10. August 2013 / / Keine Kommentare

Meine Domain ist per DNSSEC gesichert, der Webserver bietet TLS an. Mit DANE (DNS-based Authentication of Named Entities) lässt sich beides verbinden: Die Checksumme des TLS-Zertifikats wird als TLSA-Record im DNS veröffentlicht — DNSSEC schützt diesen Record vor Manipulation.

Warum DANE?

Das klassische CA-System hat ein grundsätzliches Problem: Jede der hunderten Certificate Authorities kann ein Zertifikat für jede Domain ausstellen. Wird eine CA kompromittiert oder handelt fahrlässig, können gefälschte Zertifikate im Umlauf sein — der Browser merkt nichts. DANE löst das, indem der Domaininhaber selbst festlegt, welches Zertifikat gültig ist. Der Hash steht im DNS, DNSSEC garantiert die Integrität. Keine CA kann das unterlaufen.

Unterstützt ein Client DANE, prüft er beim TLS-Handshake, ob der TLSA-Record zum angebotenen Zertifikat passt. Das funktioniert auch mit selbstsignierten Zertifikaten — solange der Hash stimmt und DNSSEC aktiv ist, wird dem Zertifikat vertraut. Die Spezifikation steht in RFC 6698.

TLSA-Record erstellen

Der TLSA-Record enthält einen Hash des Public Keys (SPKI) aus dem Zertifikat. Mit OpenSSL erzeugt:

openssl x509 -in server.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Den Hash trägt man als TLSA-Record in die DNS-Zone ein. Für den Webserver (Port 443):

_443._tcp.www.kernel-error.de. 3600 IN TLSA 3 1 1 a321...f7

Die drei Zahlen 3 1 1 bedeuten:

  • 3 — DANE-EE (End Entity): Das Zertifikat wird direkt geprüft, kein CA-Vertrauen nötig
  • 1 — SPKI (Subject Public Key Info): Nur der Public Key wird gehasht, nicht das ganze Zertifikat. Vorteil: Bei Erneuerung mit demselben Key bleibt der TLSA-Record gültig
  • 1 — SHA-256 als Hash-Algorithmus

Der TTL von 3600 Sekunden ist bewusst kurz gewählt — bei einem Zertifikatswechsel mit neuem Key soll der alte Record schnell ablaufen.

Prüfen

Mit dig lässt sich der TLSA-Record abfragen:

dig TLSA _443._tcp.www.kernel-error.de +short
3 1 1 a321...f7

Ob der Record auch zum tatsächlich ausgelieferten Zertifikat passt, prüft man mit OpenSSL — Hash vom Server-Zertifikat erzeugen und mit dem DNS-Record vergleichen:

echo | openssl s_client -connect www.kernel-error.de:443 2>/dev/null \
  | openssl x509 -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Stimmen die Hashes überein, ist alles korrekt. Komfortabler geht es mit posttls-finger (Teil von Postfix) — das Tool prüft TLSA-Record und Zertifikat in einem Schritt.

DANE für E-Mail

DANE funktioniert nicht nur für Webserver. Für E-Mail ist es sogar wichtiger — SMTP hat kein Vertrauensmodell wie Browser, opportunistisches TLS kann trivial per Downgrade-Angriff ausgehebelt werden. Mit DANE und TLSA-Records auf Port 25 wird die Verschlüsselung kryptographisch verifizierbar. Wie man das mit Postfix einrichtet, steht im Beitrag Postfix mit DANE und DNSSEC absichern. Zur Visualisierung des DANE-Anteils im Mailverkehr habe ich damals Mailgraph um DANE-Graphen erweitert.

Siehe auch: DNSSEC einrichten

Fragen? Einfach melden.

DKIM Schüssel getauscht

12. November 2012 / / Keine Kommentare

Nachdem nun alle etwas nervös wegen zu kurzer DKIM Keys sind (512Bit), diese lassen sich wohl bei Amazon in knapp 72 Stunden knacken. Habe ich dann meine Schlüssel auch einmal getauscht. Diese hatten bisher eine Länge von 1024 Bit, mit diesen wäre ich also noch locker auf der sicheren Seite denn noch kann es ja nicht schaden sie auf 2048Bit aufzubohren. Fast alle Systeme können mit diesen inzwischen umgehen. Die Leistung aktueller Systeme sollte heute ebenfalls nicht sonderlich unter diesen Schlüssellänge leiden.

Die Schlüssel sind schnell erstellt:

$ dkim-genkey -b 2048 -s kernel-error.de -d kernel-error.de

Wie gewohnt habe ich dann den TXT-RECORD in mein Zonenfile gekippt. Beim signieren der Zone per DNSsec sprang mich aber folgende Fehlermeldung an:

dnssec-signzone: error: dns_rdata_fromtext: kernel-error.de:25: ran out of space

Na nu? Ach so… ja klar! Der TXT-RECORD ist zu lang. Da gibt es ja eine Beschränkung…. Fast vergessen! Mehr als 255 Zeichen sind ja nicht zulässig. Ich musste den DKIM TXT-RECORD also in ein multi-line TXT-RECORD umwandeln. Nicht weiter kompliziert, einfach Klammer auf, Klammer zu und alles brav mit Anführungszeichen trennen. Damit sieht mein Zoneneintrag nun wie folgt aus:

kernel-error.de._domainkey IN TXT ( "v=DKIM1; g=*; k=rsa; "
                    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1V7WG+ZchvAxfJ2wi9jn7vWVs2mDkk66cqrKjTETdbuPwL"
                    "CX4N4IXTemT7SMS2Z+gTxcPNnUCorcMsXigNlGJK4Oq8GNx0fcxbXB+vq522FpM6FY8FVTfhL7bqLg5ajp9k0boJnSRv"
                    "F4wY3nci6E7CYCdP9XjHVoOciJdlrGFMo8rYGGiI9Ubgvue8etqgPCV2T8BKEZgys7kabPyaujSHmqrPbBkjb/F+QPJH"
                    "WqcyD7ywfT5vUkrj40Qiwsr7HxGk9aYCAHwyvdP4dvXd5xfMH2QlRKbrMjIQfKJfD5cfTiAl7YgFBFO1n7Wfj5syB6FE"
                    "bRZR9HO+rusv0hojiViQIDAQAB" )

Schnell noch mit einer Testmail an: check-auth@verifier.port25.com prüfen ob alles korrekt ist.

Fertig….

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: kernel-error@kernel-error.com)
ID(s) verified: header.d=kernel-error.com
Canonicalized Headers:
    To:'20'<check-auth@verifier.port25.com>;'0D''0A'
    Subject:'20'check-auth@verifier.port25.com'0D''0A'
    MIME-Version:'20'1.0'0D''0A'
    Content-Type:'20'text/plain;'20'charset=UTF-8;'0D''0A'
    '20'format=flowed'0D''0A'
    Content-Transfer-Encoding:'20'7bit'0D''0A'
    Date:'20'Fri,'20'09'20'Nov'20'2012'20'11:33:48'20'+0100'0D''0A'
    From:'20'Sebastian'20'van'20'de'20'Meer'20'<kernel-error@kernel-error.com>;'0D''0A'
    Message-ID:'20'<c580aed4c89d48c1a93fea35ee80fe30@vandemeer.de>;'0D''0A'
    DKIM-Signature:'20'v=1;'20'a=rsa-sha256;'20'c=simple/simple;'20'd=kernel-error.com;'0D''0A'
    '09's=kernel-error.com;'20't=1352457228;'0D''0A'
    '09'bh=v55t4Oe0VsnE3Xa3exogjgnS10dkjG1rhPQxGz4STJo=;'0D''0A'
    '09'h=To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:'0D''0A'
    '09''20'Date:From:Message-ID;'0D''0A'
    '09'b=

Canonicalized Body:
    check-auth@verifier.port25.com'0D''0A'
    

DNS record(s):
    kernel-error.com._domainkey.kernel-error.com. 300 IN TXT "v=DKIM1; g=*; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtlhidIl+KZgelAOOVYiGHi+uGxEnpjmhXH2IVZNpH69ZsWYTYd1OgXIvWQnAiQ4rRCyvbjcrKaFnXJUpda9eGJeqlr3hE4YhOPLS34K86+8Gr17+WOofkdc3STmlqAI60r1+bQQh8rCWb1YPXIssinq3ll8GVDwAEmh3Bm8zSWz2Ntc+W/maURTlZbMGaRoi+lwhBzr+DnNYL+mPs3UVQoE9ei2Z/bjNQzdpzWeriFgfk56muVZNTvmn8LxkugMhoHMohCr/vkr99xTVmIeMFwMerB2B/JOpeADIf4Wsz6OJQR3GaBA91MX9T2nFncvW3pL03O4wYYVCGnFqz8gbcQIDAQAB"

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

 

Siehe auch: DKIM einrichten

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑