DANE/TLSA-Eintrag-Prüfer

Fragt die TLSA-Einträge der Mailserver (MX-Hosts) einer Domain bei mehreren öffentlichen DNS-Resolvern ab und prüft, ob DANE-Zertifikatspinning konfiguriert ist.

Tipps

  • TLSA-Einträge liegen nicht unter dem gewöhnlichen Domainnamen, sondern unter einem speziellen Namen, `_25._tcp.{MX-Host}`. Deshalb findet eine Abfrage von TLSA direkt auf der Domain nie etwas.
  • „DANE nicht konfiguriert" ist kein Fehler. DANE ist eine zusätzliche Schutzebene für die E-Mail-Verschlüsselung, und die meisten Mailserver nutzen sie noch nicht.
  • DANE ist nur vertrauenswürdig, wenn der TLSA-Eintrag der Domain selbst durch die DNSSEC-Signaturkette geschützt ist. Auch wenn ein TLSA-Eintrag gefunden wird, sollten Sie zusätzlich das Schwestertool „DNSSEC-Prüfer" nutzen, um zu bestätigen, dass DNSSEC für die Domain aktiviert ist.
  • Hat eine Domain mehrere MX-Hosts, prüft dieses Tool bis zu 3 Hosts, beginnend mit der niedrigsten Präferenznummer (höchste Priorität).
  • Stimmen die Resolver nicht überein, wurde der Eintrag möglicherweise gerade aktualisiert und die Caches sind noch nicht synchron. Warten Sie etwas und prüfen Sie erneut.

Häufig gestellte Fragen

„DANE nicht konfiguriert" ist für sich genommen nicht gefährlich – die überwiegende Mehrheit der Mailserver läuft nach wie vor ohne DANE. Dennoch lohnt es sich, die Aktivierung als Schutz vor STARTTLS-Man-in-the-Middle-Angriffen in Betracht zu ziehen, wenn die Möglichkeit besteht.

Beide zielen darauf ab, TLS-Verschlüsselung beim Mailtransport zu erzwingen, stützen ihr Vertrauen aber unterschiedlich: MTA-STS verlässt sich auf die Validierungskette einer Zertifizierungsstelle, DANE auf die DNSSEC-Signaturkette. Ist DNSSEC bereits aktiviert, ist DANE die naheliegende Wahl; andernfalls ist MTA-STS der praktischere Einstieg. Beide lassen sich auch kombinieren.

Usage legt das Validierungsmodell fest (ob weiterhin eine CA-Validierung nötig ist oder das Zertifikat selbst direkt gepinnt wird), Selector legt fest, ob das gesamte Zertifikat oder nur der öffentliche Schlüssel gehasht wird, und Matching Type legt den Hash-Algorithmus fest (z. B. SHA-256 oder SHA-512). Unterschiedliche Kombinationen passen zu unterschiedlichen Betriebsmustern.

Für vollständigen Schutz sollte jeder MX-Host, der als Zustellziel gewählt werden könnte, einen TLSA-Eintrag besitzen. Ist er nur bei einem Teil der Hosts vorhanden, bleibt E-Mail, die an einen Host ohne Eintrag zugestellt wird, ungeschützt.

Dieses Tool prüft nur einen oberflächlichen Zustand: ob ein TLSA-Eintrag veröffentlicht ist. Es prüft nicht, ob die Zertifikatszuordnungsdaten tatsächlich mit dem echten Serverzertifikat übereinstimmen. Für eine strenge Prüfung sollten Sie zusätzlich ein spezialisiertes Tool verwenden.
ツールくん

Übrigens – E-Mail-Verschlüsselung mit Zertifikaten statt nur „nicht abhören"

Die E-Mail-Verschlüsselung über SMTP (STARTTLS) hat seit Langem eine Schwachstelle. Die meisten Mailserver nutzen opportunistisches TLS – fällt die Gegenstelle nicht auf Verschlüsselung zurück, wird einfach im Klartext gesendet. Das öffnete Tür und Tor für „STRIPTLS-Angriffe", bei denen ein Man-in-the-Middle-Angreifer den STARTTLS-Befehl unbemerkt entfernt, sodass die Verbindung auf Klartext herabgestuft wird, ohne dass es einer der beiden Seiten auffällt.

DANE (DNS-based Authentication of Named Entities, RFC 6698) begegnet diesem Problem, indem TLSA-Einträge im DNS veröffentlicht werden. Indem das Zertifikat eines Mailservers (oder der Hash seines öffentlichen Schlüssels) im Voraus im DNS verankert wird, kann der sendende Server prüfen, ob der Host, mit dem er sich verbindet, tatsächlich das erwartete Zertifikat vorweist. Anders als bei der üblichen SSL/TLS-Zertifikatsprüfung verlässt sich DANE überhaupt nicht auf die Vertrauenskette einer Zertifizierungsstelle – vertraut wird ausschließlich der DNSSEC-Signaturkette.

Die Schwäche von DANE besteht darin, dass es nur funktioniert, wenn die Domain selbst mit DNSSEC signiert ist. Ohne DNSSEC lässt sich nicht ausschließen, dass der TLSA-Eintrag selbst auf dem Transportweg manipuliert wird, wodurch die Garantie von DANE bedeutungslos wird. Deshalb folgt die Verbreitung von DANE eng der von DNSSEC und hat sich bei einigen europäischen Registries (etwa .nl und .cz) bereits früher durchgesetzt.