Mehr Crypto: DANE TLSA, SSHFP
Was könnte man eigentlich noch machen, wenn man dem eigenen DNS etwas mehr Sicherheit verpasst hat? Na ja, eine Idee wäre z.B., im DNS bestimmte Aussagen über den sonstigen Einsatz von Kryptographe zu treffen. Dabei gibt es zwei Dinge, die mir sinnvoll erscheinen: Zum einen SSHFP-Records, mit denen man den Host-Key eines SSH-Servers im DNS verewigen kann, und zum anderen DANE TLSA, mit dem man selbiges etwas universeller tun kann.
Warum sollte man sich die Mühe machen? Nun, viele gemeinhin eingesetzte Protokolle unterstützen von Haus aus zwar SSL/TLS, arbeiten aber oft recht opportunistisch: Ohne weitere Konfiguration z.B. ist es bei Mailservern durchaus üblich, dass diese Nachrichten zustellen, egal, ob der Zielserver überhaupt die STARTTLS-Erweiterung anbietet. Und selbst wenn die STARTTLS-Erweiterung angeboten wird ist es unüblich, das präsentierte Zertifikat zu verifizieren - weder darauf, ob der Hostname stimmt noch ob das Zertifikat von einer vertrauenswürdigen (was auch immer das in diesen Zeiten bedeuten mag) Stelle unterzeichnet wurde. Und selbst wenn man das alles prüft: Wir haben erlebt, wie CAs in der Vergangenheit missbraucht wurden. Man kann zwar soweit gehen und die Fingerprints bestimmter Gegenstellen lokal pflegen, aber das skaliert nicht wirklich. Hier springt nun DNSSEC ein: Mit DNSSEC ist es so gut wie unmöglich, DNS-Records zu fälschen, da es, von der root-Zone abwärts, eine vertrauenswürdige Kette von Signaturen gibt, die man leicht verifizieren kann. Was liegt also näher, als besagte Fingerprints im DNS zu veröffentlichen?
Für das SSH-Protokoll wird dies durch den Einsatz der genannten SSHFP-Records erledigt. Beispiel:
|
|
Wichtig ist hier, dass die Daten auch wirklich via DNSSEC verifiziert wurden
- in meinem Query habe ich das durch den Schalter
+ad
erzwungen. Verbindet man sich nun mit entsprechenden Parametern auf den Server, so sieht man, dass eine DNS-Abfrage gestellt wurde (und sofern man einen verifizierenden Resolver verwendet, kann man sich auch darauf verlassen):
|
|
Die ausschlaggebende Zeile hier ist Matching host key fingerprint found in
DNS. Die DANE TLSA-Records ermöglichen ein vom Effekt her identisches Vorgehen
für beliebige Dienste, da sie vom Aufbau her einer ähnlichen Syntax wie
SRV-Records folgen. So habe
ich z.B. auf meinem Server mail.incertum.net
ein Zertifikat, welches ich
sowohl für die Webmail-Oberfläche als auch für den Mailempfang nutze. Die
dazugehörigen TLSA-RRs sehen wie folgt aus:
|
|
Auch hier ist wieder darauf zu achten, dass authentifizierte Daten benutzt werden. Und natürlich kann man sich überlegen, auch TLSA-RRs für den MSA-Port 587, für IMAP etc. zu deployen. Die Unterstützung für TLSA-RRs ist derzeit noch recht rudimentär, es gibt bisher ein Firefox-Plugin sowie etwas Code, um einfach TLSA/SSHFP-RRs zu erzeugen. Die aktuellen Snapshots von Postfix und Exim bieten jedoch bereits Unterstützung für DANE TLSA MX-RRs.
Wie immer gilt: Lieber zuviel Crypto als zu wenig!