18 maart 2015
Tweeluik DANE, deel II: TLSA records voor mail
DANE is een protocol voor het veilig publiceren van publieke sleutels en certificaten dat voortbouwt op DNSSEC . Hoewel DANE dus breder inzetbaar is, doet het op dit moment zijn eerste intrede met name in de wereld van de web-certificaten (HTTPS) en de beveiliging van mail-transport (SMTP). In dit artikel focussen we daarom specifiek op de inzet van DANE voor het beveiligen van TLS — officieel DANE TLSA geheten. Het eerste deel van dit tweeluik beschreef de TLSA records en hun praktische inzet voor websites. In dit tweede deel laten we zien hoe DANE gebruikt kan worden om mail gateways cryptografisch te beschermen.
De configuratie van DANE voor mail is niet veel anders dan die voor web. De mail-protocollen zijn echter aanzienlijk uitgebreider dan die voor HTTP. Om te kunnen begrijpen waar en hoe TLS precies aangrijpt, zetten we eerst de betrokken protocollen op een rijtje.
Voor mail is het van belang onderscheid te maken tussen de communicatie tussen de gebruiker en zijn mail servers enerzijds en tussen mail servers onderling anderzijds. Bij communicatie tussen de gebruiker en zijn mail servers gaat het in eerste instantie om het ophalen en lezen door de gebruiker. Zijn mail client (de MUA, Mail User Agent) gebruikt daarvoor de protocollen POP en IMAP om met de server (de MDA, Mail Delivery Agent) te communiceren. De traditionele TCP-poorten voor deze twee protocollen zijn respectievelijk 110 en 443. Voor TLS-beveiligde verbindingen zijn dat respectievelijk poortnummer 995 (POP3S) en 993 (IMAPS). Verbindingen naar de onbeveiligde poorten kunnen door de client worden opgewaardeerd naar een versleutelde verbinding middels het STARTTLS-commando. Tegenwoordig geef je in de client-configuratie meestal expliciet aan gebruik te willen maken van IMAPS op poort 993.
Voor het versturen van berichten gebruikt de mail client het SMTP-protocol. Tegenwoordig gebeurt dat meestal via een private SMTP gateway op poort 587, afgeschermd voor spammers met behulp van een paswoord. Poortnummer 465 was ooit gereserveerd voor TLS-beveiligde gateways, maar die poort is inmiddels aan een ander protocol toegewezen. Cryptografische beveiliging van deze SMTP-verbindingen gebeurt nu dus altijd via STARTTLS.
Mail transport
Voor het afleveren van berichten maakt de SMTP gateway ook weer gebruik van het SMTP-protocol. Dat gebeurt dan op poortnummer 25 van de mail server die als ingang gespecificeerd staat in het MX record. Ook hier is weer geen aparte poort beschikbaar voor TLS-beveiligde verbindingen. Clients kunnen hun verbinding met de MX gateway weer opwaarderen via het STARTTLS-commando.
Ondanks alle gelijkenissen is er een belangrijk verschil tussen SMTP-verbindingen voor het versturen van mail (door de mail client) enerzijds en die voor het afleveren van mail (bij de MX gateway) anderzijds. Beheerders van SMTP gateways kunnen hun gebruikers dwingen om STARTTLS te gebruiken als ze mail willen versturen. Dat geldt echter niet voor MX gateways: omdat zij een publieke ingang zijn voor het afleveren van berichten moeten zij (vooralsnog) ook clients kunnen bedienen die geen STARTTLS ondersteunen. In die zin lijkt de SMTP service dus op het web waar bezoekers in het algemeen ook kunnen kiezen of zij een server bezoeken op poortnummer 80 (HTTP) of op poort 443 (HTTPS). Belangrijke nuancering is wel dat een bezoeker die met https in zijn URL naar de beveiligde poort 443 surft nooit een fallback naar de onbeveiligde poort 80 zal doen, terwijl een client die een bericht wil afleveren "gedwongen" kan worden om dat onbeveiligd te doen. Een man-in-the-middle (MITM) kan immers de STARTTLS capability uit de (in eerste instantie) onbeveiligde communicatie van de server verwijderen, een tactiek die ook regelmatig door internet providers gebruikt blijkt te worden.
Opportunistisch
Hoewel DANE voor web en DANE voor mail erg op elkaar lijken, zijn er dus ook belangrijke verschillen. Waar het gebruik van 'https' in de URL impliceert dat TLS gebruikt moet worden, bestaat er niet zoiets voor mail. Uit een mail-adres of de MX records is immers niets af te leiden over de beveiliging van het transport. Wel impliceert de aanwezigheid van een TLSA record dat de SMTP gateway TLS ondersteunt, waarmee een downgrade-aanval op de STARTTLS capability van de gateway wordt voorkomen. Het gebruik van TLS door de client is echter optioneel, waarmee DANE voor mail een zogenaamd opportunistisch protocol blijft. Dat wil zeggen dat een client die zelf DNSSEC, DANE en STARTTLS ondersteunt zijn verbindingen met een server die STARTTLS en TLSA records levert moet versleutelen. Maar ontbreekt een van deze onderdelen, dan vindt noodgedwongen een fallback naar TLS zonder DANE of zelfs een volledig onbeveiligd transport plaats. Zo wordt gewaarborgd dat het afleveren van berichten — waar immers geen mens aan te pas komt — zo veel mogelijk doorgang kan vinden.
DANE usage 0 en 1, waarbij het TLSA record wordt ingezet om een PKI server-certificaat een extra verankering te geven, mogen voor DANE voor mail niet gebruikt worden. De PKI-verankering biedt voor mail geen meerwaarde ten opzichte van een self-signed certificaat met een TLSA-anker. Als DNS gecompromitteerd is, kan de aanvaller de TLSA records immers zodanig veranderen (in usage 2 of 3) dat de validatie van de PKI-vertrouwensketen sowieso niet meer vereist wordt.
Hoewel je voor DANE voor het web een vergelijkbare redenering kunt opzetten, gaan de auteurs van de standaard hierbij (om politieke redenen) uit van de huidige situatie waarin mail clients in tegenstelling tot web-browsers niet een min-of-meer gestandaardiseerde verzameling trust anchors aan boord hebben. Bovendien is de rol van HTTPS en SMTP+TLS ook verschillend: voor transacties over het web is de versleuteling cruciaal, terwijl voor mail de betrouwbare aflevering meestal belangrijker is dan de beveiliging van het transport. Vandaar ook liever die opportunistische fallback in beveiliging dan een bounce van het mail-bericht. DANE voor mail is zo ontworpen dat het een transparante beveiliging toevoegt die geen extra configuratie, trust anchors of interactie met de gebruiker nodig heeft. De ontwerpers beschouwen DANE dan ook niet als een aanvulling maar als de opvolger en vervanger van PKI-verankering.
Het TLSA record voor mail
In principe kan voor alle mail servers die via TLS of STARTTLS beveiligde verbindingen aanbieden een TLSA record aangemaakt worden. De Postfix mail server kan ook zo geconfigureerd worden dat deze DANE-validatie doet alvorens mail af te leveren bij een MX gateway. Voor zo ver ons bekend zijn er op dit moment nog geen mail clients die validatie doen op certificaten voor hun POP-, IMAP- of SMTP-verbindingen.
Gezien de ondersteuning van DANE door Postfix — na Exim de meest gebruikte MTA — is het aanmaken van een TLSA record voor de MX gateway op poort 25 nu al zinvol. We moeten daarvoor direct het server-certificaat gebruiken, want de hash-slinger en ldns toolkits ondersteunen wel TLS maar geen STARTTLS. NLnet Labs geeft aan wel plannen te hebben om STARTTLS in te bouwen in ldns, maar die hebben op dit moment geen prioriteit.
Hier is hoe we de hash-waarde voor ons certificaat met behulp van openssl zouden laten uitrekenen:
[root ~]# openssl x509 -in /var/indimail/control/servercert.pem -outform DER |
openssl sha256
(stdin)= 00d91fe1cdc6795bf48575eb3ad934b88faf9391f90464e2e518b0354bb22d07
En zo zouden we deze waarde vervolgens in ons TLSA record opnemen:
_25._tcp.mx.example.nl IN TLSA 3 0 1
00d91fe1cdc6795bf48575eb3ad934b88faf9391f90464e2e518b0354bb22d07
Op deze web-pagina kunnen we tenslotte onze DANE-configuratie voor mail laten testen:
Roll-over
Net als voor HTTPS is het ook voor mail van belang om niet te vergeten het TLSA record opnieuw aan te maken als het server-certificaat wordt vervangen. Ook hiervoor moet een complete roll-over worden uitgevoerd: Eerst moet het nieuwe TLSA record worden toegevoegd. Nadat de nieuwe RRset overal bekend is, kan het server-certificaat worden vervangen. En pas daarna kan het oude TLSA record worden weggehaald.
