Modul 5 · 5.4
Šifrirana dostava: TLS, MTA-STS in DANE
Modul 5: Ugled in veliki ponudniki · Čas branja: 10 minut
Cilj učenja: Po tej lekciji boste znali razložiti, kako poštni strežniki med seboj šifrirajo promet, zakaj to privzeto ni izvršljivo in kaj na tem spremenijo MTA-STS, TLS-RPT in DANE. Znali boste poiskati in prebrati ustrezne zapise.
Ključni pojmi: STARTTLS med strežniki, oportunistično šifriranje, napad z degradacijo (downgrade), MTA-STS (RFC 8461), zapis _mta-sts, datoteka s pravilnikom, način testing/enforce/none, TLS-RPT (RFC 8460), zapis _smtp._tls, DANE za SMTP (RFC 7672), zapis TLSA, DNSSEC
Dve vrsti povezav
V lekciji 1.4 je bilo govora o povezavi med Vašim poštnim programom in poštnim strežnikom Vašega ponudnika: vrata 587 s STARTTLS ali 465 z neposrednim TLS, z vpisom. Nad tem imate sami nadzor. Vaš program ve, kateri strežnik pričakuje, preveri certifikat in zavrne povezavo, če kaj ni v redu.
Ta lekcija govori o naslednjem koraku: povezavi med pošiljajočim strežnikom in prejemnim strežnikom, na vratih 25. Ta poteka drugače.
Oportunistično: šifriranje, kadar je mogoče
Ko strežnik dostavlja pošto, vzpostavi povezavo z MX-strežnikom prejemnika. Po ukazu EHLO preveri, ali prejemni strežnik ponuja STARTTLS. Če da, preklopi na šifrirano povezavo. Če ne, pošto preprosto dostavi nešifrirano.
Temu pravimo oportunistično šifriranje: šifriranje, kadar je mogoče, sicer pa ne. Pošiljajoči strežnik pri tem navadno ne preverja strogo certifikata. Potekel ali samopodpisan certifikat tako ni razlog za prekinitev.
Zakaj je tako? Ker mora e-pošta vedno delovati, tudi s starejšimi strežniki. Pošiljatelj ne more vedeti, ali bi prejemnik moral imeti TLS. To omogoča dva napada:
- Degradacija (downgrade). Nekdo, ki lahko prilagaja promet med prenosom, iz odgovora prejemnika odstrani besedo
STARTTLS. Pošiljatelj misli, da šifriranja ni, in pošto dostavi nešifrirano. Napadalec bere sporočilo. - Lažni MX. Nekdo, ki lahko ponareja odgovore DNS, kot MX navede svoj lastni strežnik. Ker se certifikat ne preverja, pošiljatelj tega ne opazi.
Danes skoraj vsi veliki poštni strežniki šifrirajo promet, Gmail pa od pošiljateljev zahteva uporabo TLS (lekcija 5.3). Vendar je "večinoma šifrirano" nekaj drugega kot "vedno in s pravim strežnikom". Za to obstajata dve rešitvi: MTA-STS in DANE. Obe nastavi prejemnik: s tem sporočite, da mora biti pošta na Vašo domeno vedno šifrirana, in sicer na strežniku z veljavnim certifikatom.
MTA-STS: pravilnik prek spletne strani
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) deluje z dvema sestavnima deloma.
Zapis TXT, ki pove, da pravilnik obstaja:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20261108T120000;"In datoteka s pravilnikom na stalnem mestu, dostopna prek https z veljavnim certifikatom:
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| Vrstica | Pomen |
|---|---|
mode: enforce | Dostavi samo prek TLS z veljavnim certifikatom pri enem od navedenih MX-strežnikov. Če to ne uspe, se pošta ne dostavi (ostane v čakalni vrsti) |
mode: testing | Dostavi kot običajno, vendar sporoči težave prek TLS-RPT |
mode: none | Pravilnika (ni) več |
mx: | Imena MX-strežnikov, ki morajo imeti ta certifikat; na začetku je dovoljena tudi *. |
max_age: | Kako dolgo (v sekundah) si lahko pošiljatelj zapomni pravilnik |
id= v zapisu TXT | Številka različice. Če spremenite pravilnik, spremenite tudi id, da pošiljatelji datoteko znova prenesejo |
Pametna podrobnost: pošiljatelj si pravilnik zapomni za čas, določen z max_age. Napadalec, ki pozneje odstrani besedo STARTTLS ali navede lažni MX, je takrat razkrit: pravilnik pove, da je šifriranje obvezno in kateri strežniki so veljavni. Pri prav prvi povezavi (preden je pravilnik znan) MTA-STS ne ščiti; to je znana šibka točka.
Resničen primer je gmail.com: zapis TXT _mta-sts.gmail.com obstaja, datoteka s pravilnikom na https://mta-sts.gmail.com/.well-known/mta-sts.txt pa ima nastavljen mode: enforce.
TLS-RPT: poročila o neuspelem šifriranju
Pri MTA-STS v načinu enforce lahko pošta obvisi, če je z Vašim certifikatom nekaj narobe. To želite vedeti. Za to je namenjen TLS-RPT (RFC 8460):
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"Pošiljatelji, ki podpirajo TLS-RPT (med drugim Google in Microsoft), nato dnevno pošiljajo poročilo v obliki JSON: koliko povezav je uspelo in katere niso, z razlogom (na primer potekel certifikat ali ime, ki ga ni v pravilniku). Tako kot pri poročilih DMARC (lekcija 4.5) lahko tudi ta poročila obdeluje storitev za poročanje.
Vrstni red uvajanja: najprej TLS-RPT, nato MTA-STS v načinu testing, nekaj tednov branja poročil in šele nato enforce. To je podobno postopnemu uvajanju pri DMARC: najprej opazovanje, nato strogost.
DANE: certifikat v DNS, zavarovan z DNSSEC
DANE (DNS-based Authentication of Named Entities) stvar reši drugače. V DNS nastavite zapis TLSA za vsak MX-strežnik, s prstnim odtisom certifikata ali ključa:
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5_25._tcp pomeni: za SMTP na vratih 25. Tri številke povedo, kako je treba vrednost brati. Pri poštnih strežnikih je najpogosteje uporabljen 3 1 1: "to je prstni odtis SHA-256 javnega ključa prav tega strežnika". Pojavlja se tudi 2 1 1: takrat gre za prstni odtis vmesnega certifikata.
Pošiljatelj, ki podpira DANE, zazna zapis TLSA, zahteva šifriranje in preveri, ali certifikat strežnika ustreza. Če se ne ujema, pošte ne dostavi.
Zakaj je DANE varen pred ponarejenimi odgovori DNS? Ker deluje izključno z DNSSEC (lekcija 8.1 tečaja DNS). Brez veljavne verige DNSSEC se zapisi TLSA preprosto zanemarijo. To je hkrati tudi prag za uporabo: tako Vaša domena (za MX) kot cona poštnega strežnika morata biti podpisani.
DANE nima šibke točke "prve povezave" kot MTA-STS in je zelo razširjen na Nizozemskem in v Nemčiji. internet.nl ga preverja. Microsoft podpira DANE za dohodno pošto v storitvi Exchange Online. Tudi MX-strežniki strani internet.nl imajo zapise TLSA.
Past: če zamenjate certifikat poštnega strežnika z DANE z novim ključem, se mora zapis TLSA spremeniti vnaprej: najprej dodate nov zapis, počakate, da preteče TTL, in šele nato začnete uporabljati nov ključ. V nasprotnem primeru pošiljatelji z DANE Vašo pošto zavrnejo. Pri 3 1 1 je to pomembno le, kadar se ključ spremeni, ne pa ob vsakem podaljšanju z istim ključem.
MTA-STS ali DANE?
| MTA-STS | DANE | |
|---|---|---|
| Potrebuje DNSSEC | Ne | Da |
| Kje se nahaja | Zapis TXT skupaj z datoteko s pravilnikom na spletni strani | Zapis TLSA za vsak MX-strežnik |
| Ščiti prvo povezavo | Ne | Da |
| Vzdrževanje | Vzdrževanje spletne strani in certifikata za mta-sts. | Posodobitev TLSA ob novem ključu |
Oba lahko uporabljate hkrati. RFC 8461 določa, da pošiljatelj, ki podpira DANE, daje prednost DANE, če obstajajo veljavni zapisi TLSA.
Kdo to ureja?
To nastavite za prejemno pošto na Vaši domeni. Če Vaša pošta teče prek gostiteljskega podjetja ali poštne storitve, je to odvisno od tega ponudnika:
- DANE je mogoč le, če ponudnik objavlja zapise TLSA za svoje poštne strežnike in ima Vaša domena nastavljen DNSSEC. Pri WebOké lahko DANE vklopite denimo na istem mestu kot DNSSEC (glejte spodnji članek o internet.nl); pri drugih ponudnikih deluje podobno ali pa je urejeno privzeto.
- MTA-STS lahko včasih nastavite sami, vendar mora biti
mta-sts.example.comspletna stran z veljavnim certifikatom, poznati pa morate tudi imena MX-strežnikov Vašega ponudnika. - TLS-RPT lahko vedno nastavite sami: gre zgolj za zapis TXT z naslovom za poročanje.
Za Vašo odhodno pošto Vam ni treba storiti ničesar: strežnik Vašega ponudnika določa, ali upošteva MTA-STS in DANE prejemnikov.
Povzetek
- Med poštnimi strežniki je TLS privzeto oportunističen: šifriran, kadar je mogoče, brez strogega preverjanja certifikata. To omogoča degradacijo in lažni MX.
- MTA-STS: zapis TXT
_mta-stsskupaj z datoteko s pravilnikom nahttps://mta-sts.<domena>/.well-known/mta-sts.txt; načintestingalienforce. - TLS-RPT: zapis TXT
_smtp._tlsz naslovom za poročanje, za dnevna poročila o neuspelem šifriranju. - DANE: zapis TLSA na
_25._tcp.<mx-strežnik>, deluje le z DNSSEC in ščiti tudi prvo povezavo. - Uvajajte tako kot DMARC: najprej poročila (TLS-RPT,
testing), nato strogost.
Kviz
Naloga
Naloga Z5.4: Iskanje zapisov MTA-STS, TLS-RPT in DANE. Pri gmail.com poiščite zapis MTA-STS in zapis TLS-RPT, odprite datoteko s pravilnikom in vpišite način (enforce, testing ali none). Nato pri MX-strežniku strani internet.nl poiščite zapis TLSA na _25._tcp.<mx-strežnik> in vpišite prve tri številke enega od zapisov. Dodatno: iste vprašanja za svojo lastno domeno (tam je lahko odgovor tudi "ni ga"). Program vse podatke pridobi v živo in jih primerja.
Za nadaljnje branje
Koraki v teh člankih veljajo za nadzorne plošče WebOké; pri drugih ponudnikih deluje podobno.
- Kontrolni seznam internet.nl: dosezite 100 % z Vašim spletnim mestom in e-pošto
- Kaj je DNSSEC?
- Brezplačen tečaj DNS 8.1: DNSSEC v preprostem jeziku
- internet.nl, preverite svojo e-pošto (neodvisni test STARTTLS, DANE in drugega): https://internet.nl/
- RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE za SMTP)