Šifruotas pristatymas: TLS, MTA-STS ir DANE

5 modulis: Reputacija ir didieji gavėjai · Skaitymo trukmė: 10 min.

Mokymosi tikslas: Baigę šią pamoką galėsite paaiškinti, kaip pašto serveriai tarpusavyje šifruoja ryšį, kodėl tai pagal nutylėjimą nėra privaloma, ir ką tai pakeičia su MTA-STS, TLS-RPT bei DANE. Galėsite surasti ir perskaityti atitinkamus įrašus.

Pagrindinės sąvokos: STARTTLS tarp serverių, oportunistinis (progine) šifravimas, downgrade ataka, MTA-STS (RFC 8461), _mta-sts įrašas, politikos failas, režimas testing/enforce/none, TLS-RPT (RFC 8460), _smtp._tls įrašas, DANE SMTP (RFC 7672), TLSA įrašas, DNSSEC

Dviejų rūšių ryšiai

Pamokoje 1.4 buvo kalbama apie ryšį tarp Jūsų pašto programos ir Jūsų paslaugų teikėjo pašto serverio: prievadas 587 su STARTTLS arba 465 su tiesioginiu TLS, su prisijungimu. Tą ryšį kontroliuojate patys. Jūsų programa žino, kokio serverio tikisi, patikrina sertifikatą ir atsisako jungtis, jei kažkas netinka.

Ši pamoka skirta kitam žingsniui: ryšiui tarp siunčiančio serverio ir gaunančio serverio, prievadu 25. Tas ryšys vyksta kitaip.

Oportunistinis (progine) šifravimas: šifruoti, kai įmanoma

Kai serveris pristato laišką, jis užmezga ryšį su gavėjo MX serveriu. Po EHLO jis patikrina, ar gaunantis serveris siūlo STARTTLS. Jei taip, jis pereina prie šifruoto ryšio. Jei ne, jis tiesiog pristato laišką nešifruotai.

Tai vadinama oportunistiniu (progine) šifravimu: šifruojama, kai įmanoma, kitu atveju ne. Dažniausiai siunčiantis serveris griežtai nepatikrina sertifikato. Pasibaigusio galiojimo arba paties sukurto sertifikato buvimas nėra priežastis sustabdyti siuntimą.

Kodėl taip? Todėl, kad paštas turi veikti visada, net su senais serveriais. Siuntėjas negali žinoti, ar gavėjas turėtų turėti TLS. Tai sudaro sąlygas dviem atakoms:

1. Downgrade ataka. Kažkas, galintis keisti srautą kelyje, pašalina žodį STARTTLS iš gavėjo atsakymo. Siuntėjas mano, kad šifravimo nėra, ir pristato laišką nešifruotai. Užpuolikas skaito turinį.
2. Netikras MX. Kažkas, galintis klastoti DNS atsakymus, nurodo savo paties serverį kaip MX. Kadangi sertifikatas netikrinamas, siuntėjas to nepastebi.

Šiais laikais beveik visi dideli pašto serveriai šifruoja, o Gmail reikalauja, kad siuntėjai naudotų TLS (pamoka 5.3). Tačiau „dažniausiai šifruota“ yra kas kita nei „visada ir su tinkamu serveriu“. Tam yra du sprendimai: MTA-STS ir DANE. Abu juos nustato gavėjas: jais pranešate, kad paštas Jūsų domenui visada turi būti šifruojamas, siunčiant į serverį su galiojančiu sertifikatu.

MTA-STS: politika per tinklalapį

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) veikia su dviem dalimis.

TXT įrašas, kuris nurodo, kad yra politika:

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

Ir politikos failas pastovioje vietoje, per https su galiojančiu sertifikatu:

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

Protingas sprendimas: siuntėjas prisimena politiką max_age laikotarpiui. Užpuolikas, kuris vėliau pašalina STARTTLS žodį arba nurodo netikrą MX, tuomet būna atskleidžiamas: politika sako, kad šifravimas yra privalomas ir kurie serveriai yra tinkami. Per pačią pirmąją jungtį (prieš politikai tampant žinoma) MTA-STS neapsaugo; tai yra žinomas silpnas taškas.

Tikras pavyzdys yra gmail.com: TXT įrašas _mta-sts.gmail.com egzistuoja, o politikos failas adresu https://mta-sts.gmail.com/.well-known/mta-sts.txt nurodo mode: enforce.

TLS-RPT: ataskaitos apie nepavykusį šifravimą

Kai MTA-STS nustatyta kaip enforce, paštas gali likti neišsiųstas, jei kažkas negerai su Jūsų sertifikatu. Jūs turite tai sužinoti. Tam skirtas TLS-RPT (RFC 8460):

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

Siuntėjai, palaikantys TLS-RPT (tarp jų Google ir Microsoft), kasdien siunčia ataskaitą JSON formatu: kiek ryšių pavyko ir kurie ne, nurodant priežastį (pavyzdžiui, pasibaigusio galiojimo sertifikatas arba pavadinimas, kurio nėra politikoje). Kaip ir su DMARC ataskaitomis (pamoka 4.5), galite leisti jas apdoroti ataskaitų paslaugai.

Diegimo eiliškumas: pirmiausia TLS-RPT, tada MTA-STS su testing režimu, keletą savaičių skaitykite ataskaitas, ir tik tada pereikite prie enforce. Tai panašu į DMARC rekomenduojamą tvarką: pirmiausia stebėti, tada griežtinti.

DANE: sertifikatas DNS, apsaugotas su DNSSEC

DANE (DNS-based Authentication of Named Entities) veikia kitaip. DNS įraše prie kiekvieno MX serverio įrašote TLSA įrašą su sertifikato arba rakto kontroliniu kodu (fingerprint):

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

_25._tcp reiškia: SMTP prievadui 25. Trys skaičiai nurodo, kaip reikia skaityti reikšmę. Pašto serveriams dažniausiai naudojama 3 1 1: „tai yra SHA-256 kontrolinis kodas būtent šio serverio viešojo rakto“. Taip pat pasitaiko 2 1 1: tada įraše yra tarpinio sertifikato kontrolinis kodas.

Siuntėjas, palaikantis DANE, matydamas TLSA įrašą, reikalauja šifravimo ir patikrina, ar serverio sertifikatas atitinka. Jei neatitinka, laiškas nepristatomas.

Kodėl DANE saugus nuo suklastotų DNS atsakymų? Todėl, kad jis veikia tik su DNSSEC (DNS kursas, pamoka 8.1). Be galiojančios DNSSEC grandinės TLSA įrašai ignoruojami. Tai ir yra kliūtis: tiek Jūsų domenas (dėl MX), tiek pašto serverio zona turi būti pasirašyti.

DANE neturi „pirmo karto“ silpnumo kaip MTA-STS, ir jis plačiai naudojamas Nyderlanduose bei Vokietijoje. internet.nl tai tikrina. Microsoft palaiko DANE gaunamam paštui Exchange Online sistemoje. Taip pat internet.nl MX serveriai turi TLSA įrašus.

Spąstai: jei pakeičiate pašto serverio sertifikatą su DANE nauju raktu, TLSA įrašas turi būti atitinkamai pakeistas, ir tai turi įvykti iš anksto: pirmiausia pridėti naują įrašą, palaukti, kol baigsis TTL galiojimas, ir tik tada pradėti naudoti naują raktą. Kitaip DANE naudojantys siuntėjai atmes Jūsų paštą. Su 3 1 1 tai aktualu tik tuo atveju, kai keičiasi raktas, o ne kiekvieną kartą atnaujinant su tuo pačiu raktu.

MTA-STS ar DANE?

Galite naudoti abu kartu. RFC 8461 nurodo, kad siuntėjas, palaikantis DANE, teikia pirmenybę DANE, jei yra galiojančių TLSA įrašų.

Kas tai tvarko?

Tai nustatote gaunamam paštui savo domene. Jei Jūsų paštas veikia pas prieglobos arba pašto paslaugos teikėją, viskas priklauso nuo jo:

• DANE galima tik tuo atveju, jei paslaugų teikėjas skelbia TLSA įrašus savo pašto serveriams ir Jūsų domenas turi DNSSEC. WebOké galite, pavyzdžiui, įjungti DANE toje pačioje vietoje kaip DNSSEC (žr. internet.nl straipsnį žemiau); kitų paslaugų teikėjų atveju tai veikia panašiai arba yra sutvarkyta pagal nutylėjimą.
• MTA-STS kartais galite nustatyti patys, bet tuomet mta-sts.example.com turi būti tinklalapis su galiojančiu sertifikatu ir turite žinoti savo paslaugų teikėjo MX pavadinimus.
• TLS-RPT visada galite nustatyti patys: tai tik TXT įrašas su ataskaitų adresu.

Dėl Jūsų siunčiamo pašto nieko daryti nereikia: Jūsų paslaugų teikėjo serveris nusprendžia, ar jis gerbia gavėjų MTA-STS ir DANE.

Santrauka

• Tarp pašto serverių TLS pagal nutylėjimą yra oportunistinis (progine): šifruojama, kai įmanoma, be griežto sertifikato tikrinimo. Tai sudaro sąlygas downgrade atakai ir netikram MX.
• MTA-STS: TXT _mta-sts plius politikos failas adresu https://mta-sts.<domenas>/.well-known/mta-sts.txt; režimas testing arba enforce.
• TLS-RPT: TXT _smtp._tls su ataskaitų adresu, skirtas kasdienėms ataskaitoms apie nepavykusį šifravimą.
• DANE: TLSA įrašas adresu _25._tcp.<mx-serveris>, veikia tik su DNSSEC ir apsaugo taip pat pirmąjį ryšį.
• Diekite kaip DMARC: pirmiausia ataskaitos (TLS-RPT, testing), tada griežtinimas.

Testas

Užduotis

Užduotis Z5.4: MTA-STS, TLS-RPT ir DANE paieška. Suraskite domenui gmail.com MTA-STS įrašą ir TLS-RPT įrašą, atidarykite politikos failą ir nurodykite režimą (enforce, testing arba none). Tada suraskite internet.nl MX serveriui TLSA įrašą adresu _25._tcp.<mx-serveris> ir nurodykite pirmuosius tris vieno iš įrašų skaičius. Papildomai: tuos pačius klausimus patikrinkite savo domenui (ten atsakymas gali būti „nėra“). Programa visus duomenis patikrina gyvai ir palygina.

Skaitykite daugiau

Šiuose straipsniuose aprašyti žingsniai galioja WebOké valdymo skydeliams; kitų paslaugų teikėjų atveju veikia panašiai.

• Internet.nl kontrolinis sąrašas: pasiekite 100% su Jūsų svetaine ir el. paštu
• Kas yra DNSSEC?
• Nemokamas DNS kursas 8.1: DNSSEC paprasta kalba
• internet.nl, patikrinkite savo el. paštą (nepriklausomas STARTTLS, DANE ir kitų dalykų testas): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE skirtas SMTP)