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:

1
2
dig thrassa.incertum.net sshfp +ad +short
1 1 275EF12B1816FBA59E7D5F4C73898CA8B7AA48DD

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):
1
2
3
4
5
ssh -o "VerifyHostKeyDNS ask" thrassa.incertum.net
The authenticity of host 'thrassa.incertum.net (78.47.238.19)' can't be established.
RSA key fingerprint is 13:0f:0e:4e:2c:1a:ab:5d:55:55:2a:86:37:93:7e:b9.
**Matching host key fingerprint found in DNS.**
Are you sure you want to continue connecting (yes/no)?

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:

1
2
3
for i in _25 _443; do dig $i._tcp.mail.incertum.net tlsa +ad +short; done
3 1 1 BD52FE11E0F91400911340805F4BB7A55C8F1717E8ADF22AA072E37B 68336BB6
3 0 1 2895EA9D138D8963009756BDBCD563AC5EC803E5A84F481D54A4CB2D 242DA874

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!