TLSA + DNSSEC
DANE
DANE pentru SMTP leaga certificatul TLS al serverului de email de DNSSEC, folosind recorduri TLSA publicate pentru fiecare MX.
Ce este DANE
DANE inseamna DNS-Based Authentication of Named Entities. In zona de email, DANE permite unui domeniu sa publice in DNS informatii despre certificatul TLS asteptat pe serverul SMTP. Diferenta fata de verificarea TLS clasica este ca increderea nu vine doar din lantul unei autoritati de certificare publice, ci si din DNSSEC. Daca DNSSEC este valid, receiverul poate spune: pentru acest MX, pe portul 25, certificatul sau cheia trebuie sa corespunda acestui TLSA.
DANE este un flag puternic, dar mai pretentios operational decat MTA-STS. Ai nevoie de DNSSEC corect, de TLSA pentru MX-uri si de disciplina la schimbarea certificatelor. Daca certificatul se schimba si TLSA ramane vechi, senderii care valideaza DANE pot refuza livrarea. De aceea DANE trebuie administrat atent, mai ales in infrastructuri cu certificate automate.
Recordul TLSA
Pentru SMTP, TLSA se publica sub numele _25._tcp.mx.example.com, unde mx.example.com este hostname-ul serverului MX. Recordul contine patru parti: certificate usage, selector, matching type si datele de asociere. O configuratie comuna pentru certificate controlate de operator este usage 3, selector 1 si matching type 1, adica hash SHA-256 al cheii publice.
_25._tcp.mx1.example.com. TLSA 3 1 1 2A3B4C...
Selectorul stabileste daca se verifica certificatul intreg sau doar SubjectPublicKeyInfo. Matching type stabileste daca se publica valoarea completa sau un hash. Alegerea trebuie sa fie compatibila cu modul in care reinnoiesti certificatele. Daca folosesti aceeasi cheie la reinnoire, un TLSA pe cheia publica poate supravietui schimbarii certificatului; daca cheia se schimba, trebuie actualizat TLSA.
De ce DNSSEC este obligatoriu
DANE fara DNSSEC nu are sens de securitate. Un atacator care poate modifica raspunsurile DNS ar putea modifica atat MX-ul, cat si TLSA-ul. DNSSEC creeaza lantul de incredere de la zona parinte pana la recordurile semnate. Pentru email, nu este suficient ca TLSA-ul de pe MX sa fie semnat daca domeniul destinatarului nu are MX-uri validate DNSSEC. Atacatorul ar putea schimba raspunsul MX catre alt server.
De aceea Mailcheck diferentiaza intre TLSA valid pe MX si DANE complet pentru domeniul destinatar. Daca infinitytelecom.ro nu este semnat DNSSEC, dar mx1.infinitynet.ro are TLSA valid, rezultatul corect este partial: TLSA este valid pentru MX, dar protectia DANE completa pentru domeniul destinatar nu exista.
DANE partial vs DANE complet
DANE complet inseamna ca traseul DNS pentru domeniul destinatarului, recordurile MX si TLSA-urile MX-urilor este validat. DANE partial apare cand unele bucati sunt corecte, dar lipseste o parte din lant. De exemplu, toate MX-urile pot avea TLSA, dar domeniul destinatar nu are DS/DNSKEY. Sau domeniul este semnat, dar numai unul dintre MX-uri are TLSA. In acest caz este mai corect un status WARN/PARTIAL decat PASS.
DANE lipsa este MISSING, nu FAIL. FAIL apare cand domeniul a publicat date DANE, dar acestea sunt defecte: TLSA invalid, lant DNSSEC rupt, hash care nu se potriveste cu certificatul sau SERVFAIL cauzat de DNSSEC broken.
Cum interpretezi statusul
- PASS - domeniul si MX-urile au DNSSEC valid, fiecare MX are TLSA valid, iar TLSA se potriveste cu certificatul SMTP.
- MISSING - nu exista TLSA sau DNSSEC necesar. Este lipsa de configurare, nu defect.
- WARN - configuratia este partiala: unele MX-uri au TLSA, altele nu, sau TLSA este valid dar MX-ul domeniului destinatar nu este protejat DNSSEC.
- FAIL - TLSA sau DNSSEC exista, dar este invalid si poate rupe livrarea.
Ce verifica Mailcheck
Mailcheck verifica DNSSEC pe domeniul destinatar, validarea MX-urilor, existenta TLSA pentru fiecare MX, validarea DNSSEC a TLSA-urilor si potrivirea TLSA cu certificatul observat pe SMTP STARTTLS. In raport, flagul DANE trebuie citit impreuna cu DNSSEC si cu rezultatul certificatului. Un certificat valid CA poate fi acceptabil pentru MTA-STS, dar DANE are propria logica de validare prin TLSA.