Titkosított kézbesítés: TLS, MTA-STS és DANE

Modul 5: Reputáció és a nagy szolgáltatók · Olvasási idő: 10 perc

Tanulási cél: E lecke után el tudja magyarázni, hogyan titkosítanak egymás között a levelezőszerverek, miért nem kikényszeríthető ez alapértelmezés szerint, és mit változtat ezen az MTA-STS, a TLS-RPT és a DANE. Képes lesz a rekordokat megkeresni és elolvasni.

Kulcsfogalmak: STARTTLS a szerverek között, opportunista titkosítás, downgrade-támadás, MTA-STS (RFC 8461), _mta-sts-rekord, házirendfájl, testing/enforce/none mód, TLS-RPT (RFC 8460), _smtp._tls-rekord, DANE SMTP-hez (RFC 7672), TLSA-rekord, DNSSEC

Kétféle kapcsolat

Az 1.4 leckében a saját levelezőprogramja és a szolgáltatójának levelezőszervere közötti kapcsolatról volt szó: 587-es port STARTTLS-sel, vagy 465-ös port közvetlen TLS-sel, bejelentkezéssel. Ott Ön maga rendelkezik az irányítással. A programja tudja, melyik szervert várja, ellenőrzi a tanúsítványt, és megtagadja a kapcsolódást, ha valami nem stimmel.

Ez a lecke a következő lépésről szól: a küldő szerver és a fogadó szerver közötti kapcsolatról, a 25-ös porton. Ez másképp zajlik.

Opportunista: titkosítás, ha lehet

Amikor egy szerver levelet kézbesít, kapcsolódik a címzett MX-szerveréhez. Az EHLO után megnézi, hogy a fogadó szerver felajánlja-e a STARTTLS-t. Ha igen, áttér a titkosított kapcsolatra. Ha nem, egyszerűen titkosítatlanul kézbesíti a levelet.

Ezt hívják opportunista titkosításnak: titkosítás, ha lehet, egyébként nem. És a küldő szerver többnyire nem ellenőrzi szigorúan a tanúsítványt. Egy lejárt vagy saját kezűleg készített tanúsítvány ilyenkor nem ok a megállásra.

Miért van ez így? Mert a levelezésnek mindig működnie kell, még a régi szerverekkel is. A küldő nem tudhatja, hogy a fogadónak kellene-e TLS-t használnia. Ez két támadást tesz lehetővé:

1. Downgrade. Aki útközben módosítani tudja a forgalmat, kiveszi a STARTTLS szót a fogadó válaszából. A küldő azt hiszi, nincs titkosítás, és titkosítatlanul kézbesít. A támadó olvassa a levelezést.
2. Hamis MX. Aki meg tudja hamisítani a DNS-válaszokat, saját szerverét adja meg MX-ként. Mivel a tanúsítványt nem ellenőrzik, a küldő semmit nem vesz észre.

Manapság szinte minden nagy levelezőszerver titkosít, és a Gmail elvárja a küldőktől a TLS használatát (5.3 lecke). De a „legtöbbször titkosított” más, mint a „mindig, és a megfelelő szerverrel”. Erre két megoldás van: az MTA-STS és a DANE. Mindkettőt a fogadó állítja be: így tudatja, hogy a domainjére érkező levelet mindig titkosítani kell, érvényes tanúsítvánnyal rendelkező szerveren.

MTA-STS: házirend egy weboldalon keresztül

Az MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) két elemből áll.

Egy TXT-rekord, amely jelzi, hogy van házirend:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261108T120000;"

Valamint egy házirendfájl egy rögzített helyen, https-en keresztül, érvényes tanúsítvánnyal:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

A trükk a következő: a küldő megjegyzi a házirendet a max_age időtartamára. Egy támadó, aki később eltávolítja a STARTTLS szót vagy hamis MX-et ad meg, ilyenkor lebukik: a házirend kimondja, hogy a titkosítás kötelező, és megadja, mely szerverek érvényesek. A legelső kapcsolódáskor (mielőtt a házirend ismertté válna) az MTA-STS nem véd; ez az ismert gyenge pont.

Valós példa a gmail.com: a _mta-sts.gmail.com TXT-rekord létezik, és a https://mta-sts.gmail.com/.well-known/mta-sts.txt házirendfájlban mode: enforce szerepel.

TLS-RPT: jelentések a sikertelen titkosításról

MTA-STS enforce módban a levél megakadhat, ha valami baj van a tanúsítvánnyal. Ön szeretne erről tudni. Erre szolgál a TLS-RPT (RFC 8460):

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"

A TLS-RPT-t támogató küldők (többek között a Google és a Microsoft) naponta küldenek jelentést JSON-formátumban: hány kapcsolódás sikerült és melyik hiúsult meg, az okkal együtt (például lejárt tanúsítvány vagy olyan név, amely nem szerepel a házirendben). Ahogy a DMARC-jelentéseknél (4.5 lecke), ezeket is feldolgoztathatja jelentésfeldolgozó szolgáltatással.

Bevezetési sorrend: először TLS-RPT, aztán MTA-STS testing módban, néhány hétig jelentések olvasása, és csak azután enforce. Ez hasonlít a DMARC fokozatos bevezetésére: előbb megfigyelés, aztán szigorítás.

DANE: a tanúsítvány a DNS-ben, DNSSEC-kel védve

A DANE (DNS-based Authentication of Named Entities) másképp közelíti meg a kérdést. A DNS-ben minden MX-szerverhez beállít egy TLSA-rekordot, amely a tanúsítvány vagy a kulcs lenyomatát tartalmazza:

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5

A _25._tcp azt jelenti: SMTP-hez, a 25-ös porton. A három szám megmondja, hogyan kell értelmezni az értéket. Levelezőszerverekhez a 3 1 1 a leggyakoribb: „ez pontosan ennek a szervernek a nyilvános kulcsának SHA-256-lenyomata”. A 2 1 1 is előfordul: ilyenkor egy köztes tanúsítvány lenyomata szerepel benne.

Egy DANE-t támogató küldő látja a TLSA-rekordot, megköveteli a titkosítást, és ellenőrzi, hogy a szerver tanúsítványa illeszkedik-e. Ha nem illeszkedik, nem kézbesít.

Miért biztonságos a DANE a hamisított DNS-válaszokkal szemben? Mert csak DNSSEC-kel működik (DNS-tanfolyam 8.1 lecke). Érvényes DNSSEC-lánc nélkül a TLSA-rekordokat figyelmen kívül hagyják. Ez egyúttal a belépési küszöb is: mind a domainjének (az MX-hez), mind a levelezőszerver zónájának alá kell lennie írva.

A DANE-nek nincs „első alkalom” gyengesége, mint az MTA-STS-nek, és Hollandiában és Németországban széles körben használják. Az internet.nl ezt is teszteli. A Microsoft támogatja a DANE-t a bejövő levelekhez az Exchange Online-ban. Az internet.nl MX-szerverei is rendelkeznek TLSA-rekordokkal.

Buktató: ha egy DANE-t használó levelezőszerver tanúsítványát új kulcsra cseréli, a TLSA-rekordnak is változnia kell, méghozzá előre: először az új rekordot adja hozzá, várjon, amíg a TTL lejár, és csak azután vegye használatba az új kulcsot. Ellenkező esetben a DANE-t használó küldők visszautasítják a levelét. A 3 1 1 esetén ez csak akkor számít, ha a kulcs megváltozik, nem minden megújításnál, ha ugyanaz a kulcs marad.

MTA-STS vagy DANE?

Egymás mellett is használhatók. Az RFC 8461 kimondja, hogy a DANE-t támogató küldő a DANE-t részesíti előnyben, ha érvényes TLSA-rekordok vannak.

Ki intézi ezt?

Ezt a fogadott levelezéshez állítja be a domainjén. Ha a levelezése egy tárhelyszolgáltatónál vagy levelezési szolgáltatónál fut, az adott félen múlik:

• A DANE csak akkor lehetséges, ha a szolgáltató TLSA-rekordokat tesz közzé a levelezőszervereihez, és az Ön domainjén be van kapcsolva a DNSSEC. A WebOké-nál például ugyanazon a helyen kapcsolhatja be a DANE-t, mint a DNSSEC-et (lásd az alábbi internet.nl-cikket); más szolgáltatóknál ez hasonlóan működik, vagy alapértelmezés szerint be van állítva.
• Az MTA-STS-t néha Ön is beállíthatja, de ehhez az mta-sts.example.com-nak érvényes tanúsítvánnyal rendelkező weboldalnak kell lennie, és ismernie kell a szolgáltatója MX-neveit.
• A TLS-RPT-t mindig beállíthatja saját maga: ez csupán egy TXT-rekord egy jelentési címmel.

A kimenő leveleihez semmit nem kell tennie: a szolgáltatója szervere dönti el, hogy tiszteletben tartja-e a fogadók MTA-STS-ét és DANE-jét.

Összefoglalás

• A levelezőszerverek között a TLS alapértelmezés szerint opportunista: titkosított, ha lehet, szigorú tanúsítványellenőrzés nélkül. Ez lehetővé teszi a downgrade-et és a hamis MX-et.
• MTA-STS: TXT _mta-sts plusz házirendfájl a https://mta-sts.<domain>/.well-known/mta-sts.txt címen; testing vagy enforce mód.
• TLS-RPT: TXT _smtp._tls egy jelentési címmel, napi jelentésekhez a sikertelen titkosításról.
• DANE: TLSA-rekord a _25._tcp.<mx-szerver> címen, csak DNSSEC-kel működik, és az első kapcsolódást is védi.
• Vezesse be úgy, mint a DMARC-ot: először jelentések (TLS-RPT, testing), aztán szigorítás.

Kvíz

Feladat

Z5.4 feladat: MTA-STS, TLS-RPT és DANE keresése. Keresse meg a gmail.com esetében az MTA-STS-rekordot és a TLS-RPT-rekordot, nyissa meg a házirendfájlt, és töltse ki a módot (enforce, testing vagy none). Ezután keresse meg az internet.nl egyik MX-szerverének TLSA-rekordját a _25._tcp.<mx-szerver> helyen, és töltse ki az egyik rekord első három számát. Opcionális: ugyanezek a kérdések a saját domainjéhez (ott a válasz lehet „nincs”). A program élőben kérdezi le és hasonlítja össze az adatokat.

További olvasnivaló

Az ezekben a cikkekben leírt lépések a WebOké vezérlőpultjaira vonatkoznak; más szolgáltatóknál ez hasonlóan működik.

• Internet.nl ellenőrzőlista
• Mi az a DNSSEC?
• Ingyenes DNS-tanfolyam 8.1: A DNSSEC közérthetően
• internet.nl, tesztelje le a levelezését (a STARTTLS, a DANE és más elemek független tesztje): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE SMTP-hez)