Bezpečnější předávání pošty s TLSA záznamy

E-mail je protokol starší než internet samotný, přesto je to stále ještě jeden z nejpoužívanějších komunikačních nástrojů. Kvůli svému stáří ovšem neobsahuje žádné bezpečnostní prvky a je tak velmi snadné poštu odposlechnout, modifikovat, přesměrovat nebo jednoduše nechat zmizet. V průběhu let proto vznikly nástroje rozšiřující starý protokol o některé prvky – například šifrování pomocí TLS.

Šifrovat můžeme jak end-to-end mezi uživateli, tak i komunikaci mezi samotnými servery. Druhá možnost nevyžaduje žádnou akci na straně uživatele a přesto chrání poštu po většinu její cesty. Pravdou sice je, že takto poslanou poštu mohou číst správci obou serverů (odesílacího i přijímacího), ale i přesto jde o významné zlepšení vylučující z komunikace vliv třetí strany.

Oportunistické šifrování

Současný systém přenosu elektronické pošty pracuje tak, že server oznámí novému klientovi možnost navázat TLS spojení pomocí zprávy STARTTLS. Pokud se klient rozhodne pro šifrování, zahájí se anonymní TLS spojení a pošta se přenese. Pokud ovšem z nějakého důvodu TLS spojení selže, pošta se přenese nešifrovaně. Zároveň se v tomto oportunistickém systému nehledí na vlastnosti certifikátů – vyhoví i slabé šifry, neověřuje se důvěryhodnost vydavatele, ba ani platnost. Certifikát je tak vlastně jen zbytečnou obálkou pro veřejný klíč.

Pokud bychom chtěli sami přejít na dogmatický systém a vynucovat při odesílání platnost všech zmíněných položek, odeslali bychom jen velmi málo pošty. Jak ukazuje měření Ondřeje Caletky ze sdružení CESNET, čtvrtina SMTP serverů nepodporuje přenos pošty šifrovaným kanálem.

Další měření pak ukazuje, že asi jen 60 % serverů má důvěryhodný certifikát vystavený na jméno domény příjemce pošty nebo jméno serveru. Ostatní certifikáty jsou buď self-signed, nedůvěryhodné nebo vystavené na naprosto jiné jméno.

I kdybychom ale trvali na důvěryhodném certifikátu vystaveném pro správné jméno serveru, neřeší to zásadní problém: útočník může podvrhnout DNS záznam a tvrdit, že poštu pro root.cz vyřizuje MX server bad.example.com. Ten může mít platný certifikát, reverzní záznam a splňovat všechny technické náležitosti. Přesto to není náš správný server pro příjem pošty a tu začne získávat útočník. Ani si toho nemusíme všimnout, protože nám poštu bude posílat zase zpět.

Bezpečně s DNSSEC a TLSA

Naštěstí na oba zmíněné problémy existují ty správné léky. Začneme od konce: proti podvržení MX záznamů v DNS slouží elektronické podpisy DNSSEC, které dovolují klientovi vždy ověřit, že dostal validní informace vydané správcem domény. Když už máme takto zajištěný bezpečný kanál, můžeme do něj klientovi přidat i otisk klíče z TLS certifikátu. K tomu slouží DNS záznam typu TLSA definovaný v RFC 6698 s doplněním informací o použití se SMTP v RFC 7672.

Zatím se nepodařilo dostat podporu do webových prohlížečů, ale při přenosu pošty je tento systém velmi dobře použitelný. Dělá přesně to, co potřebujeme: umožňuje vynechat ze hry certifikační autority (což poštovní servery stejně dělají) a nahradit je jiným pevným bodem důvěry – podepsaným záznamem v DNS. V takové situaci můžeme rovnou přejít na dogmatické šifrování a vynutit předávání šifrované pošty. Jinými slovy: příjemce deklaruje bezpečné šifrování, takže vědomě potvrzuje možnost jeho použití.

Pokud tedy v doméně existuje TLSA záznam, bude klient vyžadovat certifikát se správným veřejným klíčem – na jiných parametrech certifikátu stále nezáleží. Pokud ale dojde k chybě a druhá strana se platným certifikátem neprokáže, odesílatel na chybu reaguje nedoručením pošty. Nelze tedy provést downgrade attack a tvrdit, že příjemce stejně hodlá použít nešifrovaný kanál. Podle hesla: jednou jsme se dohodli na zabezpečení, tak to musí být bezpečné.

V současné době tento postup při doručování pošty podporuje server Postfix od verze 2.11 (leden 2014) a podpora pro Exim a OpenSMTPd se připravuje.

Praktická část

Nejprve je potřeba mít na serveru certifikát a privátní klíč. Ten můžeme získat od své autority nebo si můžeme klidně vygenerovat nový. Stačí k tomu jediný příkaz:

$ openssl req -x509 -new -newkey rsa:2048 -keyout klic.pem -out self.pem -nodes

Všechny dotazy je možné přeskočit pomocí klávesy enter. Doporučuji ale minimálně vyplnit položku Common Name čistě z provozních důvodů, abyste měli při setkání s tímto certifikátem možnost zjistit, kde se vlastně vzal.

Generujeme TLSA

Dále je potřeba vygenerovat samotné TLSA záznamy, které ovšem pro účely SMTP nesmí používat usage typ 0 a 1. Nejlepší je použít typ 3 s otiskem koncového certifikátu serveru. K tomu slouží buďto webový generátor nebo pythonovská utilita Swede:

$ swede create --port 25 --protocol tcp --output rfc --usage 3 --selector 1 --mtype 1 --certificate self.pem mail.example.com

Výstupem je přímo DNS záznam, který je potřeba vložit do zónového souboru k mail serveru:

_25._tcp.mail.example.com. IN TLSA 3 1 1 1fff7351cdb3957d2d3edd0f7d48bb6246f25361006c1f83379b85c6f3071adc

Výsledek můžeme ověřit ve webovém testu dane.sys4.de:

Případně můžete použít utilitu posttls-finger , která je součástí balíčku se serverem Postifx. Na posledním řádku vypíše, že spojení bylo ověřeno pomocí TLSA:

$ posttls-finger -c nebezi.cz
posttls-finger: warning: /etc/postfix/main.cf, line 54: overriding earlier entry: smtpd_sender_restrictions=reject_unknown_sender_domain
posttls-finger: using DANE RR: _25._tcp.www.nebezi.cz -> _443._tcp.nebezi.cz IN TLSA 3 1 1 16:A2:E8:57:5B:C4:F0:93:54:34:74:6E:01:9F:92:AA:7F:56:74:5B:90:BE:61:AE:10:6E:7E:AC:0D:40:F6:AD
posttls-finger: www.nebezi.cz[2001:1528:132:70::ebe2]:25: depth=0 matched end entity public-key sha256 digest=16:A2:E8:57:5B:C4:F0:93:54:34:74:6E:01:9F:92:AA:7F:56:74:5B:90:BE:61:AE:10:6E:7E:AC:0D:40:F6:AD
posttls-finger: www.nebezi.cz[2001:1528:132:70::ebe2]:25: Matched subjectAltName: *.nebezi.cz
posttls-finger: www.nebezi.cz[2001:1528:132:70::ebe2]:25: Matched subjectAltName: nebezi.cz
posttls-finger: www.nebezi.cz[2001:1528:132:70::ebe2]:25 CommonName *.nebezi.cz
posttls-finger: www.nebezi.cz[2001:1528:132:70::ebe2]:25: subject_CN=*.nebezi.cz, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=0D:21:DF:56:0C:97:27:23:BB:27:53:4D:B6:15:C1:5F:95:BA:5D:60, pkey_fingerprint=E1:CA:77:D8:25:CA:6D:80:15:D0:07:45:31:A1:23:AA:1F:F8:5A:DF
posttls-finger: Verified TLS connection established to www.nebezi.cz[2001:1528:132:70::ebe2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Validace při předání

Nakonec je možné v mail serveru Postfix aktivovat validaci při předávání pošty. Stačí přidat do konfigurace tři řádky. Nejlepší je využít utility postconf, která dovoluje atomicky upravovat konfigurační soubor a ověřuje správnost syntaxe.

# postconf -e "smtp_dns_support_level = dnssec"
# postconf -e "smtp_tls_security_level = dane"
# postconf -e "smtp_tls_loglevel = 1"

V logu se pak začnou objevovat záznamy o tom, zda se podařilo ověřit spojení pomocí TLSA záznamu.

Nov 11 23:20:10 server Verified TLS connection established to www.nebezi.cz[2001:1528:132:70::ebe2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov 11 23:20:24 server Untrusted TLS connection established to mx1.seznam.cz[77.75.76.42]:25: TLSv1.2 with cipher AES128-SHA (128/128 bits)
Nov 11 23:20:51 server Anonymous TLS connection established to stana.iinfo.cz[213.151.94.130]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)

První záznam ukazuje server, který má správně uložený platný TLSA záznam. Druhý server TLSA záznam vůbec neobsahuje (nemá ani DNSSEC) a třetí server během šifrování vůbec nenabízí certifikát. Všechny stavy popisuje dokumentace Postfixu.

Rotace TLSA záznamů

V případě změny certifikátů nesmí správce zapomenout vyměnit také TLSA záznam. Jelikož DNS není synchronizovaný systém, nemůžeme nijak zajistit okamžitou změnu na všech místech světa. Správný postup má tedy dva kroky: přidat do DNS nový otisk certifikátu, počkat alespoň dobu TTL a poté teprve certifikáty doopravdy vyměnit.

Využívá se toho, že v DNS můžou být duplicitní záznamy s různými hodnotami. Vůbec tedy nevadí, když bude v zóně více TLSA záznamů – ten platný ale nesmí nikdy chybět. Klient si mezi více záznamy vybere ten správný. Starý záznam můžeme odstranit kdykoliv později.

Děkuji Ondřeji Caletkovi ze sdružení CESNET a Ondřeji Surému ze sdružení CZ.NIC.