5. modulis · 5.4
Šifrēta nogādāšana: TLS, MTA-STS un DANE
5. modulis: Reputācija un lielie pakalpojumu sniedzēji · Lasīšanas laiks: 10 minūtes
Mērķis: Pēc šīs nodarbības Jūs varēsiet izskaidrot, kā pasta serveri savstarpēji šifrē, kāpēc tas pēc noklusējuma nav obligāti izpildāms, un ko tur maina MTA-STS, TLS-RPT un DANE. Jūs varēsiet atrast un izlasīt attiecīgos ierakstus.
Pamatjēdzieni: STARTTLS starp serveriem, oportūnistiska šifrēšana, pazeminošā (downgrade) uzbrukums, MTA-STS (RFC 8461), _mta-sts ieraksts, politikas fails, režīms testing/enforce/none, TLS-RPT (RFC 8460), _smtp._tls ieraksts, DANE SMTP vajadzībām (RFC 7672), TLSA ieraksts, DNSSEC
Divu veidu savienojumi
1.4. nodarbībā bija runa par savienojumu starp Jūsu pasta programmu un Jūsu pakalpojumu sniedzēja pasta serveri: ports 587 ar STARTTLS vai 465 ar tiešu TLS, ar pieteikšanos. Tur kontrole ir Jūsu rokās. Jūsu programma zina, kuru serveri tā sagaida, pārbauda sertifikātu un atsakās savienoties, ja kaut kas neatbilst.
Šī nodarbība ir par nākamo soli: savienojumu starp nosūtošo serveri un saņemošo serveri, portā 25. Tas notiek citādi.
Oportūnistiski: šifrē, ja iespējams
Kad serveris nogādā pastu, tas izveido savienojumu ar saņēmēja MX serveri. Pēc EHLO tas pārbauda, vai saņemošais serveris piedāvā STARTTLS. Ja jā, tas pāriet uz šifrētu savienojumu. Ja nē, tas vienkārši nogādā pastu nešifrētā veidā.
To sauc par oportūnistisku šifrēšanu: šifrē, ja iespējams, citādi ne. Un parasti nosūtošais serveris stingri nepārbauda sertifikātu. Beidzies termiņš vai pašizveidots sertifikāts tad nav iemesls apturēt procesu.
Kāpēc tā? Tāpēc, ka pastam vienmēr jāturpina darboties, pat ar vecākiem serveriem. Nosūtītājs nevar zināt, vai saņēmējam vajadzētu izmantot TLS. Tas rada iespēju diviem uzbrukumu veidiem:
- Pazemināšana (downgrade). Kāds, kas var mainīt satiksmi ceļā, izņem vārdu
STARTTLSno saņēmēja atbildes. Nosūtītājs domā, ka šifrēšanas nav, un nogādā pastu nešifrētā veidā. Uzbrucējs lasa saturu. - Viltus MX. Kāds, kas var viltot DNS atbildes, norāda savu serveri kā MX. Tā kā sertifikāts netiek pārbaudīts, nosūtītājs to nepamana.
Mūsdienās gandrīz visi lielie pasta serveri šifrē, un Gmail pieprasa no nosūtītājiem TLS lietošanu (5.3. nodarbība). Bet "parasti šifrēts" nav tas pats, kas "vienmēr un ar pareizo serveri". Tam ir divi risinājumi: MTA-STS un DANE. Abus iestata saņēmējs: ar tiem Jūs paziņojat, ka pastam uz Jūsu domēnu vienmēr jābūt šifrētam, izmantojot serveri ar derīgu sertifikātu.
MTA-STS: politika caur tīmekļa lapu
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) darbojas ar divām sastāvdaļām.
TXT ieraksts, kas paziņo, ka pastāv politika:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20261108T120000;"Un politikas fails fiksētā vietā, pieejams caur https ar derīgu sertifikātu:
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| Rinda | Nozīme |
|---|---|
mode: enforce | Nogādājiet pastu tikai caur TLS ar derīgu sertifikātu pie viena no minētajiem MX serveriem. Ja tas neizdodas, nenogādāt (pasts paliek rindā) |
mode: testing | Nogādājiet pastu kā parasti, bet ziņojiet par problēmām ar TLS-RPT palīdzību |
mode: none | Politikas (vairs) nav |
mx: | To MX serveru nosaukumi, kuriem jānes sertifikāts; *. sākumā ir pieļaujams |
max_age: | Cik ilgi (sekundēs) nosūtītājs drīkst paturēt politiku atmiņā |
id= TXT ierakstā | Versijas numurs. Ja maināt politiku, mainiet arī id, lai nosūtītāji failu atkārtoti ielādētu |
Gudrā daļa: nosūtītājs atceras politiku max_age norādīto laiku. Uzbrucējs, kurš vēlāk izņem vārdu STARTTLS vai uzrāda viltus MX, tad tiek atklāts: politika nosaka, ka šifrēšana ir obligāta un kuri serveri ir derīgi. Pašā pirmajā savienojumā (pirms politika ir zināma) MTA-STS neaizsargā; tas ir zināmais vājais punkts.
Reāls piemērs ir gmail.com: TXT ieraksts _mta-sts.gmail.com pastāv, un politikas fails vietnē https://mta-sts.gmail.com/.well-known/mta-sts.txt ir iestatīts uz mode: enforce.
TLS-RPT: pārskati par neveiksmīgu šifrēšanu
Ja MTA-STS ir iestatīts uz enforce, pasts var palikt iestrēdzis, ja ar Jūsu sertifikātu kaut kas nav kārtībā. Jūs vēlaties par to zināt. Tam paredzēts TLS-RPT (RFC 8460):
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"Nosūtītāji, kas atbalsta TLS-RPT (tostarp Google un Microsoft), tad katru dienu nosūta pārskatu JSON formātā: cik savienojumi bijuši veiksmīgi un kuri neveiksmīgi, ar iemeslu (piemēram, beidzies sertifikāta termiņš vai nosaukums, kura nav politikā). Tāpat kā ar DMARC pārskatiem (4.5. nodarbība), Jūs varat likt tos apstrādāt kādam pārskatu pakalpojumam.
Secība ieviešanai: vispirms TLS-RPT, tad MTA-STS režīmā testing, dažas nedēļas lasiet pārskatus, un tikai pēc tam enforce. Tas līdzinās DMARC pakāpeniskajai ieviešanai: vispirms vērot, tad kļūt stingram.
DANE: sertifikāts DNS, aizsargāts ar DNSSEC
DANE (DNS-based Authentication of Named Entities) risina to citādi. Jūs DNS ievietojat TLSA ierakstu katram MX serverim ar sertifikāta vai atslēgas atlasi (fingerprint):
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5_25._tcp nozīmē: SMTP portā 25. Trīs skaitļi norāda, kā vērtība jālasa. Pasta serveriem visbiežāk lieto 3 1 1: "šis ir precīzi šī servera publiskās atslēgas SHA-256 atlase". Sastopams arī 2 1 1: tad tajā ir starpsertifikāta atlase.
Nosūtītājs, kas atbalsta DANE, redz TLSA ierakstu, pieprasa šifrēšanu un pārbauda, vai servera sertifikāts atbilst. Ja neatbilst, tas pastu nenogādā.
Kāpēc DANE ir drošs pret viltotām DNS atbildēm? Tāpēc, ka tas strādā tikai ar DNSSEC (DNS kursa 8.1. nodarbība). Bez derīgas DNSSEC ķēdes TLSA ieraksti tiek ignorēti. Tas arī ir slieksnis: gan Jūsu domēnam (MX dēļ), gan pasta servera zonai jābūt parakstītai.
DANE nav tādas "pirmās reizes" vājības kā MTA-STS, un tas plaši izmantots Nīderlandē un Vācijā. internet.nl to pārbauda. Microsoft atbalsta DANE ienākošajam pastam Exchange Online. Arī internet.nl MX serveriem ir TLSA ieraksti.
Slazds: ja nomaināt pasta servera sertifikātu ar DANE pret jaunu atslēgu, TLSA ierakstam jāmainās līdzi, un tas jādara iepriekš: vispirms pievienojiet jauno ierakstu, nogaidiet, kamēr paiet TTL, un tikai tad sāciet lietot jauno atslēgu. Citādi DANE nosūtītāji noraidīs Jūsu pastu. Ar 3 1 1 tas ir aktuāli tikai tad, ja mainās atslēga, nevis katrā atjaunošanā ar to pašu atslēgu.
MTA-STS vai DANE?
| MTA-STS | DANE | |
|---|---|---|
| Vajadzīgs DNSSEC | Nē | Jā |
| Kur tas atrodas | TXT ieraksts un politikas fails tīmekļa vietnē | TLSA ieraksts katram MX serverim |
| Aizsargā pirmo savienojumu | Nē | Jā |
| Uzturēšana | Jāuztur vietne un sertifikāts mta-sts. domēnam | Jāatjaunina TLSA, mainoties atslēgai |
Abus var izmantot vienlaikus. RFC 8461 nosaka, ka nosūtītājs, kas atbalsta DANE, dod priekšroku DANE, ja pieejami derīgi TLSA ieraksti.
Kas to nokārto?
To iestata saņemošajam pastam Jūsu domēnā. Ja Jūsu pasts darbojas pie kāda hostinga uzņēmuma vai pasta pakalpojumu sniedzēja, tas ir atkarīgs no šī sniedzēja:
- DANE ir iespējams tikai tad, ja pakalpojumu sniedzējs publicē TLSA ierakstus saviem pasta serveriem un Jūsu domēnam ir DNSSEC. Piemēram, WebOké varat ieslēgt DANE tajā pašā vietā, kur DNSSEC (skatiet internet.nl rakstu zemāk); pie citiem sniedzējiem tas darbojas līdzīgi vai ir iestatīts pēc noklusējuma.
- MTA-STS reizēm varat iestatīt pats, bet tad
mta-sts.example.comjābūt tīmekļa vietnei ar derīgu sertifikātu, un Jums jāzina sava sniedzēja MX nosaukumi. - TLS-RPT vienmēr varat iestatīt pats: tas ir vienkārši TXT ieraksts ar pārskata adresi.
Jūsu izejošajam pastam nekas nav jādara: Jūsu sniedzēja serveris izlemj, vai tas ievēro saņēmēju MTA-STS un DANE.
Kopsavilkums
- Starp pasta serveriem TLS pēc noklusējuma ir oportūnistisks: šifrē, ja iespējams, bez stingras sertifikāta pārbaudes. Tas padara iespējamu pazemināšanas (downgrade) uzbrukumu un viltus MX.
- MTA-STS: TXT
_mta-stsun politikas fails vietnēhttps://mta-sts.<domēns>/.well-known/mta-sts.txt; režīmstestingvaienforce. - TLS-RPT: TXT
_smtp._tlsar pārskata adresi, dienas pārskatiem par neveiksmīgu šifrēšanu. - DANE: TLSA ieraksts
_25._tcp.<mx-serveris>, strādā tikai ar DNSSEC un aizsargā arī pirmo savienojumu. - Ieviesiet tāpat kā DMARC: vispirms pārskati (TLS-RPT,
testing), tad stingri.
Tests
Uzdevums
Uzdevums Z5.4: MTA-STS, TLS-RPT un DANE meklēšana. Atrodiet domēnam gmail.com MTA-STS ierakstu un TLS-RPT ierakstu, atveriet politikas failu un norādiet režīmu (enforce, testing vai none). Pēc tam atrodiet kādam internet.nl MX serverim TLSA ierakstu uz _25._tcp.<mx-serveris> un norādiet pirmos trīs skaitļus no viena no ierakstiem. Papildus: tie paši jautājumi par Jūsu pašu domēnu (atbilde tur var būt "nav"). Programma visu pārbauda tiešsaistē un salīdzina.
Tālākai lasīšanai
Soļi šajos rakstos attiecas uz WebOké paneļiem; pie citiem pakalpojumu sniedzējiem tas darbojas līdzīgi.
- Internet.nl kontrolsaraksts: sasniedziet 100% ar Jūsu tīmekļa vietni un e-pastu
- Kas ir DNSSEC?
- Bezmaksas DNS kurss 8.1: DNSSEC vienkāršā valodā
- internet.nl, pārbaudiet savu e-pastu (neatkarīgs STARTTLS, DANE un citu elementu tests): https://internet.nl/
- RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE SMTP vajadzībām)
