Mein Datenhaufen zu IT und Elektronik Themen.

Schlagwort: DANE

DNSsec, DANE; TLSA, Postfix… Was ist da gerade los?

Man man man… Was ist denn da passiert? Seit 3 oder 4 Tagen scheint das Thema im Internet irgendwie besonders aktiv zu sein, oder? Nur warum?!?!

Plötzlich bekomme ich nicht nur jeden Tag einen Haufen Anfragen zu dem Thema, viel scheinen auch irgendwas testen zu wollen und pumpen E-Mails mit Random-Empfängern an meine Domains….

Im Grunde habe ich ja nichts gegen Tests. Nur grob abgesprochen wäre schon schön, mein Monitoring wird sonst immer so „wuschig“! 😀

Um noch mal ein paar Themen zusammen zu fassen:

1. Basis von allem ist DNSsec
2. TLSA Records „ist DANE“
3. Postfix kann TLSA Records auswerden, ohne selbst welche für sein System zu haben.

Mein kleines DNSSEC Howto

DNSSEC und DNS-based Authentication of Named Entities (DANE)

Postfix SSL/TLS gesichert mit TLSA / DANE und DNSSEC

DNSSEC fähiger Registrar

TLSA / DANE RECORD von Hand manuel prüfen.

So long…

Postfix SSL/TLS gesichert mit TLSA / DANE und DNSSEC

Mein Domains sind nun schon seit langem per DNSSEC gesichert. Schnell habe ich auch TLSA-RECORDS für mein SSL/TLS X.509 Zertifikat des Webservers Apache veröffentlicht, damit die verschlüsselte Verbindung zu meiner Webseite ebenfalls per DANE gesichert ist.

DNSSEC: https://www.kernel-error.de/dnssec

DANE: https://www.kernel-error.de/dnssec/tls-ssl-zertifikatschecksummen-im-dns

Seit Januar diesen Jahres beherscht nun Postfix ebenfalls die Möglichkeit TLSA Records zu prüfen. Da mache ich natürlich mit!

Zuerst muss die Postfix Version natürlich passen. Kleiner 2.11 sollte es nicht sein, die Postfixversion zeigt sich schnell per:

$ postconf -d | grep mail_version
mail_version = 2.11.0

Mein Mailserver bietet natürlich schon immer die Möglichkeit einer verschlüsselten Verbindung an. Daher gehe ich einfach mal nicht näher darauf ein, wie man sein Postfix dazu überredet. Ganz kurz… Aktivieren lässt sich die Unterstützung für DANE / TLSA mit folgenden drei Konfigurationsänderungen:

$ postconf -e "smtpd_use_tls = yes"
$ postconf -e "smtp_dns_support_level = dnssec"
$ postconf -e "smtp_tls_security_level = dane"

Keine Sorge, alles bietet einen Failback an, so leidet die Kommunikation mit _nicht_ DANE fähigen Systemen nicht.

Zum erstellen des TLSA-RECORDS muss selbstverständlich nicht unbedingt der von mir in früheren Beiträgen erwähnte Hash-slinger eingesetzt werden. Openssl macht dieses fast genau so schnell.

$ openssl x509 -in postfix.pem -outform DER | openssl sha256
(stdin)= 94c8e1bdfff4f6d3fec0c4e2f26293d78870650bfd3534e77b93cdaccb77eb95

Aus diesem Hash erstelle ich nun den TLSA RECORD. Für die E-Mail Kommunikation ist es mir lieb, wenn der TTL (Lebensdauer) des Records nicht ZU lange ist. Bei einem Zertifikatswechsel dauert es sonst unnötig lange bis der neue Record gültig ist. Daher setzte ich ihn auf 1 Stunde.

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

Wie zu sehen ist biete ich den TLSA RECORD direkt für Port TCP 25 und TCP 465 an. Schnell nur noch testen ob der TLSA RECORD mit dig auch sauber abgefragt werden kann.

$ dig _25._tcp.smtp.kernel-error.de +dnssec +m

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> _25._tcp.smtp.kernel-error.de +dnssec +m
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.smtp.kernel-error.de. IN A

;; AUTHORITY SECTION:
kernel-error.de.        86400 IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                                20140102708 ; serial
                                10000      ; refresh (2 hours 46 minutes 40 seconds)
                                1800       ; retry (30 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
kernel-error.de.        86400 IN RRSIG SOA 7 2 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                QXUpVl3myVAUGn/ox8J5aihAySHdWpojyPuhV5QKgDUy
                                qYRPyryWyBoGG+x5cGs0JpPBqQA3lRovAM4JFvC3hRmO
                                FU3fVTiYlvAJK7WsTSgPJLYpXrBnS+NN0O2UW3W+Ru1K
                                2P5dj+BWNO1wqXs+VU7WpMPwq/ESlK88hxXE1Gc= )
_25._tcp.smtp.kernel-error.de. 86400 IN NSEC _465._tcp.smtp.kernel-error.de. RRSIG NSEC TLSA
_25._tcp.smtp.kernel-error.de. 86400 IN RRSIG NSEC 7 5 86400 20150511054702 (
                                20140516054702 38150 kernel-error.de.
                                ToC8GtXFenieGjA32eoHACNGCg+tFr05vz6w9yiHYrDj
                                rHGBabc7MMjqUWNsf7L059YhR7dLoAPqhy2ZThWqFbRD
                                ZsfPQSgHIazEuKvOE7i2Ee/znU2d57X8nVkp8scUKZ1R
                                kGdK5DUDlAcYn0YdpjYaUTn2STdbM9IDcdrASPE= )

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mo Jan 27 08:50:36 2014
;; MSG SIZE  rcvd: 506

Schon lässt sich im Postfix Logfile erkennen ob Verbindungen getraut wird oder nicht.

Jan 27 08:32:02 mailserver postfix/smtp[3779]: Verified TLS connection established to mx02.example.de[99.88.12.167]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 27 08:33:19 mailserver postfix/smtp[3779]: Untrusted TLS connection established to smtp2.example.de[2001:333:6661:99::34]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Wenn man mich fragt, ist die Kombination aus DNSSEC, DANE / TLSA deutlich besser als dieses hässliche EmiG. EmiG benötigt eine unnötig teure Zertifizierung durch den TüV, dieses kann sich nicht jeder leisten. Damit ist dieses „sichere“ Verfahren fast nur durch Unternehmen zu realisieren die genug Kohle haben. Kleinere werden damit einfach abgehängt. Verfahren die Sicherheit nur für „reiche“ zur Verfüfung stellen sollte man aus meiner Überzeugnung nicht unterstützen.

Eine weitere schnelle und einfache Möglichkeit seinen TLSA-RECORD des Mailservers / Postfix zu testen ist posttls-finger:

$ posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de
posttls-finger: initializing the client-side TLS engine                                                                                                                                                                          
posttls-finger: using DANE RR: _25._tcp.smtp.kernel-error.de IN TLSA 1 0 1 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95                                                       
posttls-finger: setting up TLS connection to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25                                                                                                                                  
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"                                                                                        
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA                      
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 verify=1 subject=/description=y0xkuso3gx7t8h0o/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=smtp.kernel-error.de/emailAddress=postmaster@kernel-error.de                                                                                                                                                                                                   
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 matched end entity certificate sha256 digest 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95         
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: subject_CN=smtp.kernel-error.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=E1:92:93:D4:CA:E9:5D:44:B5:CC:A4:15:1F:12:A6:E0:B5:C2:97:56, pkey_fingerprint=E9:84:8E:51:47:99:90:53:0B:2C:2E:1E:70:6E:DE:CA:A4:65:8A:C5                                                                                                                                             
posttls-finger: Verified TLS connection established to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

So bei Fragen, einfach fragen 🙂


09-08-2014 Update

Ich habe zur Auswertung den Mailgraph etwas angepasst ( mailgraph Graphen um DANE erweitern ). Dieser wirft mir nun den unten stehenden Graphen für ausgehende Verbindungen raus.

DNSSEC und DNS-based Authentication of Named Entities (DANE)

Schon einige Zeit ist meine Domain per DNSSEC geschützt und der Zugriff ist ebenfalls per SSL/TLS möglich. Mit DANE (DNS-based Authentication of Named Entities) ist es jetzt möglich die eingesetzten X.509 Zertifikate bzw. deren Checksummen mit dem DNS „abzugleichen“.

Die Idee dahinter ist, das löchrige System der CAs (certificate authority oder certification authority) etwas sicherer zu machen / zu ersetzten.

Unterstützt ein Client, wie zum Beispiel ein Browser, DANE so kann er beim verschlüsselten Verbindungsaufbau mit einem Server (z.B.: Webserver). Prüfen ob die Checksumme des TLS Zertifikates mit der in der DNS Zone hinterlegten übereinstimmt. So kann man diesem Zertifikat „trauen“, selbst wenn es sich um ein selbst signiertes Zertifikat handelt oder das Root-Zertifikat der CA nicht in seinem Client enthalten ist.

Selbstverständlich wird damit nicht sichergestellt das die angegebene Person oder Organisation wirklich hinter dem Zertifikat steht. Hier hängt es dann wieder an der CA, der muss man zum einen selbst vertrauen und zum anderen sollte sie dafür sorgen dass niemand an ihre Zertifikate kommt. Nichts ist 100%tig sicher! Man kann nur versuchen dem absoluten Vertrauen so nahe wie möglich zu kommen. Daher ist es sehr angenehem wenn verschiedene Mechanismen ineinandergreifen und sich nach Möglichkeit auch gegenseitig prüfen.

Dabei sollte der Benutzer aber mit so wenig technischen Dingen gequält werden wie nur möglich. DNSSEC, DANE und TLS ist aus meiner Sicht im Moment eine recht gute Kombination. Wenn alles sauber im Client implementiert ist und die Admins ihre Arbeit gemacht haben, bekommt der Benutzer nur die Information: „Was du da gerade machst ist möglicherweise nicht der Server mit dem du sprechen wolltest. Lass es lieber!“

Klar steht und fällt am Ende alles mit dem Benutzer. Hier müssen die Benutzer geschult und aufgeklährt werden. Den technischen Hintergrund muss aber kein Anwender verstehen. 

Ich stehe ja auf so etwas. Daher habe ich es direkt bei mir implementiert.

Bind kann ab der Version 9.8.3 mit TLSA RECORDS umgehen:

#### SCHNIPP ####
Feature Changes

* BIND now recognizes the TLSA resource record type, created to
support IETF DANE (DNS-based Authentication of Named Entities)
[RT #28989]
#### SCHNAPP ####

Damit es einfacher wird bietet die Internet Society (http://www.internetsociety.org/deploy360/resources/hashslinger-a-tool-for-creating-tlsa-records-for-dane/) ein Tool mit dem Namen Hash-slinger an. Dieses Tool unterstützt beim erstellen der TLSA-RECORDS und natürlich bei der Prüfung der DNS-RECORDS.

Für meine Hauptdomain findet sich folgender RECORD in der Zone:

_443._tcp.www.kernel-error.de. IN TLSA 3 0 1 a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7

Geprüft wird dieser korrekt wie folgt, einmal für die IPv4 und einmal für die IPv6 Adresse:

$ ./tlsa -d -v www.kernel-error.de
Received the following record for name _443._tcp.www.kernel-error.de.:
Usage: 3 (End-Entity)
Selector: 0 (Certificate)
Matching Type: 1 (SHA-256)
Certificate for Association: a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7
This record is valid (well-formed).
Attempting to verify the record with the TLS service...
Got the following IP: 212.23.142.146
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de
Got the following IP: 2001:7d8:8001:100::dead:beef
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de

Die gängigen Browser lassen sich bereits mit Plugins nachrüsten.

Spannende Infos zum Thema DANE gibt es hier:
http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec

Wer nur schnell und einfach die TLSA Records testen möchte, kann dieses hier tun: http://check.sidnlabs.nl/dane/


U-P-D-A-T-E 28.01.2014

Wie sich das Thema zusammen mit Postfix nutzen lässt um auch etwas gegen dieses hässliche EmiG (E-Mail made in Germany) zu tun ist hier zu finden: https://www.kernel-error.de/kernel-error-blog/260-postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec


U-P-D-A-T-E 09.08.2014

Ich habe den Mailgraph erweitert ( mailgraph Graphen um DANE erweitern ), damit er mir den unten stehenden Graphen erzeugt.

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑