DNSSEC, TLSA und DANE
Diesen Beitrag schrieb ich 8 Jahre und 6 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
In meinem letzten Artikel hatte ich es sozusagen geteasert: sysadmama.de liegt bei einem anderen Anbieter, läuft über DNSSEC und hat für die Ports 443, 25 und 465 TLSA-Einträge zum Zwecke der DANE-Verifizierung. In diesem Artikel möchte ich meine Vorgehensweise festhalten – und einen kleinen Ausblick wagen.
Umzug der Domain
Dass meine Domains bei Schlundtech lagen, hatte sozusagen historische Gründe: vor zehn Jahren habe ich bei 1&1 gearbeitet, da war es sehr vorteilhaft für mich, ich hostete ein paar Domains für Freunde, und die Konditionen waren gut. Auf mein jetziges Anforderungsprofil passte Schlundtech als Anbieter jedoch nicht mehr – unter anderem deshalb, weil die partout kein DNSSEC anbieten, ich aber DNSSEC haben will. Mit meinem VPS bin ich nunmehr seit über einem Jahr bei OVH und sehr zufrieden (und nein, dies ist kein sponsored post!) – und da OVH DNSSEC optional anbietet lag es nahe, die nächst fällige Domain zu übertragen. Es kostete mich nicht mehr als 15 Minuten, und die Ausfallzeiten durch die DNS-Umstellung waren kaum einer Erwähnung wert. Die Domain lief nun also unter neuer Flagge und über DNSSEC – Zeit für die TLSA-Einträge.
TLSA - Einträge im DNS
Der TLSA-Eintrag, der für jeden benötigten Port in den DNS gesetzt wird, beinhaltet die Prüfsumme des verwendeten Zertifikats; ein Client kann fortan (sofern er technisch dazu in der Lage ist zumindest) diese Prüfsumme, die er im DNS findet, mit der des ausgelieferten Zertifikats abgleichen. Stimmen beide überein, so darf der Client davon ausgehen, der Verbindung trauen zu dürfen – sogar dann, wenn es sich um ein selbst signiertes Zertifikat handelt. Oder halt eines, dessen Root-Zertifikat der CA nicht installiert ist. Eine Lösung, die 100%ige Sicherheit garantiert, wird es nie geben – so ähnlich wie bei Verhütungsmitteln, eh? ;-) Aber die Kombination von DNSSEC, TLS und DANE ist dann doch vertrauenerweckender als ein einfacher Aufruf über HTTP. Außerdem: es ist Technik-Gefummel, und ich will es einfach mal ausprobieren. Also los.
Gemäß RFC 6698 möchte ich mir meine TLSA-Einträge basteln und die Prüfsumme meines Zertifikats ermitteln – dafür gibt es sogar einen Online-Generator. Doch auch auf der Kommandozeile ist es keine Zauberei, und wie ihr seht: erwartungsgemäß ergibt jeder Aufruf ohnehin das identische Ergebnis. Genau diesen resultierenden String habe ich bei OVH (über change in Text format) eingesetzt. Es ist eine DNSSEC-Modifikation – dauert natürlich eine Weile, bis sie greift, dann kannst du deinen TLSA-Eintrag natürlich auch mit dig betrachten (hier am Beispiel SMTP):
$ dig TLSA _25._tcp.sysadmama.de +dnssec +m
...
;_25._tcp.sysadmama.de. IN TLSA
;; ANSWER SECTION:
_25._tcp.sysadmama.de. 3577 IN TLSA 3 1 1 (
1F4AED51B4FD072DFB6E7728CA74AD44E5F73DDA58D1
E872D24EED93FB288581 )
_25._tcp.sysadmama.de. 3577 IN RRSIG TLSA 7 4 3600 (
20160521133239 20160421133239 38450 sysadmama.de.
BuDjHQKXCYBherhYs12+a0fzqbdMKRNyBMerlliJ2dCN
ZnsvSTYa/13Dl/iTLl8vPmEYuu/aZPLX8or5rm/oD2A6
cOaEEeYTUQuQ3WUBc3VDv+NTYzKXJKXAeS6lo9Zl1jm/
MZCn2NyYD7kpiMhXLk2n7zzmRJB0Bd2ZJKkCJCQ= )
...
hash-slinger
$ apt-get install hash-slinger
$ tlsa --usage 1 --selector 1 --mtype 1 --output rfc --certificate /etc/nginx/ssl/sysadmama.de.crt sysadmama.de
_443._tcp.sysadmama.de. IN TLSA 1 1 1 1f4aed51b4fd072dfb6e7728ca74ad44e5f73dda58d1e872d24eed93fb288581
swede
$ git clone https://github.com/pieterlexis/swede.git
Cloning into 'swede'...
remote: Counting objects: 186, done.
remote: Total 186 (delta 0), reused 0 (delta 0), pack-reused 186
Receiving objects: 100% (186/186), 45.73 KiB | 0 bytes/s, done.
Resolving deltas: 100% (91/91), done.
Checking connectivity... done.
$ cd swede/
$ ./swede create -s 1 -o rfc sysadmama.de
No certificate specified on the commandline, attempting to retrieve it from the server sysadmama.de.
Attempting to get certificate from 51.254.103.92
Got a certificate with Subject: /C=DE/CN=www.sysadmama.de/emailAddress=postmaster@sysadmama.de
_443._tcp.sysadmama.de. IN TLSA 1 1 1 1f4aed51b4fd072dfb6e7728ca74ad44e5f73dda58d1e872d24eed93fb288581
Testen der Einstellungen
Browser unterstützen per se (noch) keine Verifizierung, doch es gibt bereits Extensions – so erhält man schon beim Aufruf jeder Webseite ein Feedback, ob sie über DNSSEC gesichert ist und DANE unterstützt. Alternativ dazu bietet beispielsweise auch auch das Webfrontend der SIDNlabs die Möglichkeit, selektiv Prüfungen zu starten. Über die VerisignLABS lassen sich die DNSSEC-Parameter der Domain sehr detailliert ausgeben und prüfen – ein wertvolles Werkzeug vor allem dann, wenn du deinen eigenen DNSSEC-fähigen Nameserver aufsetzen willst. Den DANE SMTP Validator hätte ich in dem Zusammenhang sehr gerne ausprobiert, aber für mich funktioniert der nicht, der läuft sich einfach tot – vielleicht hast du ja mehr Glück.
ldnsutils
$ apt-get install ldnsutils
$ ldns-dane -d verify sysadmama.de 465
51.254.103.92 dane-validated successfully
swede
$ ./swede verify sysadmama.de
Received the following record for name _443._tcp.sysadmama.de.:
Usage: 1 (End-Entity Constraint + chain to CA)
Selector: 1 (SubjectPublicKeyInfo)
Matching Type: 1 (SHA-256)
Certificate for Association: 1f4aed51b4fd072dfb6e7728ca74ad44e5f73dda58d1e872d24eed93fb288581
This record is valid (well-formed).
Attempting to verify the record with the TLS service...
Got the following IP: 51.254.103.92
SUCCESS (Usage 1): Certificate offered by the server matches the one mentioned in the TLSA record and chains to a valid CA certificate
The matched certificate has Subject: /C=DE/CN=www.sysadmama.de/emailAddress=postmaster@sysadmama.de
Anmerkung zu postfix
Vergangene Woche wurde ich von meiner liebsten Ex-Twitter-Timeline mal wieder tüchtig gebashed, weil ich freiwillig sendmail einsetze (und auch noch selbst kompiliere); ausschlaggebend für die Umstellung auf postfix war für mich, dass sendmail DANE nicht unterstützt, postfix hingegen schon – zumindest, wenn er in einer Version ≥ 2.11 verwendet wird. Außerdem ist es dann zwingend, ausschließlich DNSSEC-fähige Nameserver zu verwenden – zum Testen habe ich mir den Google-DNS 8.8.8.8 in die /etc/resolv.conf gesetzt. postfix bringt beispielsweise posttls-finger zum Testen mit:
$ posttls-finger -a ipv4 -c -l dane -L summary sysadmama.de
posttls-finger: Verified TLS connection established to sysadmama.de[51.254.103.92]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
In den Logs des Mailservers ist dann ersichtlich, wenn gesicherte Verbindungen aufgebaut werden – hier beispielsweise zu einem Gmail-SMTP:
postfix/submission/smtp[28950]: Trusted TLS connection established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Fazit
Mit OVH als Provider bin ich ohnehin sehr zufrieden, und im Laufe der nächsten Monate – wenn spiller.me und urban-exploring.eu verlängert werden wollen – werden auch diese beiden umziehen und entsprechend konfiguriert werden. Ist man derzeit auch noch ein wenig Pionier auf dem DANE-Gebiet, so denke ich doch, dass dem in den nächsten Jahren eine gewisse Relevanz nicht abgesprochen werden kann – das wird man sehen. Einige Anbieter – beispielsweise Posteo oder mailbox.org – bieten es bereits an. Erforderlich für den Einsatz wäre die flächendeckende Nutzung von DNSSEC – und davon sind wir denn doch noch ein ganzes Stück entfernt.
Hintergrundbild: 584x 720px, Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten