Avaldage MTA-STS ja TLS-RPT esmalt testrežiimis

SPF, DKIM ja DMARC takistavad teistel teie nime võltsimist (saate kontrollida oma DMARC-kirjet), kuid ükski neist ei takista saatvat serverit toimetamast kirja teieni lahtise tekstina. MTA-STS võimaldab avaldada poliitika, mis ütleb, et teie meiliserverid toetavad autenditud TLS-i, ja TLS-RPT annab teada, kui saatjad seda ei saanud. Mõlemad saab kasutusele võtta kahe DNS-kirje ja ühe tekstifailiga ning alustada režiimis, mis on mõeldud pehmeks kasutuselevõtuks.

Mida STARTTLS lahtiseks jätab

Serverite vaheline meilikrüpteerimine kasutab STARTTLS-laiendust ja see on oportunistlik. RFC 8461 kirjeldab nõrka kohta: ründaja, kes suudab SMTP-sessioonist "250 STARTTLS" vastuse kustutada või selle ümber suunata, kirjutades üle lahendatud MX-kirje, võib sundida kasutama nõrgemat kaitset (downgrade) või sessiooni pealt kuulata.

DANE on teine lahendus, mis on määratletud dokumendis RFC 7672, kuid see nõuab DNSSEC-i. MTA-STS tugineb selle asemel sertifitseerimiskeskustele ega vaja DNSSEC-i, "kuid sellega kaasneb pahatahtlike downgrade-rünnete risk", nagu RFC ise ütleb. Kui kasutate juba DANE-t, need ei ole vastuolus: MTA-STS-i toetavad saatjad ei tohi lasta sellel tühistada ebaõnnestunud DANE-valideerimist.

NCSC e-posti turvalisuse juhend ütleb, et teie teenus peaks suutma e-kirju TLS-iga saata ja vastu võtta ning et peaksite kaitsma kõiki oma domeene, sealhulgas neid, mis asuvad pilveteenuse pakkujate juures, näiteks Google G Suite ja Microsoft O365.

Esimene samm: poliitika testrežiimis

MTA-STS koosneb kahest osast. TXT-kirje aadressil _mta-sts.example.com teatab, et poliitika on olemas, ja annab selle versiooni:

_mta-sts.example.com. IN TXT "v=STSv1; id=20250101000000Z;"

id koosneb tähtedest ja numbritest, on kuni 32 märki pikk ja peab poliitika selle versiooni üheselt tuvastama. Järjestust see ei eelda, seega on ajatempel pigem harjumus kui nõue. Avaldage täpselt üks selline kirje: saatjad jätavad kõrvale kirjed, mis ei alga tekstiga v=STSv1;, ja kui ülejäänud kirjete arv pole üks, eeldavad nad, et teil poliitikat pole.

Poliitika ise laaditakse HTTPS-i kaudu kindlalt aadressilt, mis moodustatakse, lisades teie domeeni ette mta-sts:

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

Serveerige seda sisutüübiga text/plain, sest saatjatel on kästud meediatüüpi kontrollida. Fail näeb välja selline:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

Iga mx: rida on eraldi kirje, kas täielik hostinimi või metamärgiga järelliide, näiteks *.example.net. Loetlege kõik oma kehtivates MX-kirjetes olevad hostid, sealhulgas pilveteenuse pakkuja omad.

Režiime on kolm: enforce, testing ja none. RFC kirjeldab testing-režiimi kui valikulist režiimi, mis võimaldab pehmet kasutuselevõttu poliitika vigade avastamiseks, ja seepärast tasubki sellest alustada.

Väärtus max_age on sekundites, kuni 31557600, ning 604800 (üks nädal) on RFC enda näide. RFC ootab tootmiskeskkonna väärtusi tavaliselt nädalate või pikema ajavahemiku vahemikus. Minu soovitus: hoidke see testimise ajal nädalas või lühemana, et parandatud poliitika jõuaks saatjateni kiiresti, ning suurendage seda, kui enforce on olnud stabiilne.

Teine samm: lülitage sisse TLS-RPT

Avastamine töötab ainult siis, kui saatjad annavad teada, mida nad nägid. Avaldage TXT-kirje aadressil _smtp._tls.example.com:

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

rua võib olla ka https URI, mille puhul saatjad saadavad aruande sellele POST-päringuga, ning lubatud on komadega eraldatud loend. Nagu MTA-STS-i kirje puhul, peab täpselt üks TXT-kirje algama tekstiga v=TLSRPTv1;, vastasel juhul eeldavad saatjad, et te seda ei toeta.

Kui valite mailto, kasutage selleks eraldi postkasti. Saatjad toimetavad need aruanded kohale ka siis, kui TLS ebaõnnestub, seega võib aruanne saabuda krüpteerimata kujul. E-kirjaga saadetud aruandel peab olema aruandva domeeni kehtiv DKIM-allkiri ja RFC kohaselt peavad vastuvõtjad allkirjata aruanded eirama. Kõrvaldage allkirjata aruanded, mitte ärge nende põhjal tegutsege.

Kontrollige, mida saatjad näevad

Päringute ja poliitikafaili laadimise tehke oma võrgust väljastpoolt:

dig TXT _mta-sts.example.com
dig TXT _smtp._tls.example.com
curl -si https://mta-sts.example.com/.well-known/mta-sts.txt

dig väljundis peaks olema üks kirje mõlema kohta ja v= eesliide esimesena. curl väljundis peaks olema 200, Content-Type: text/plain ja poliitika sisu, seega kontrollige, et mode ja iga mx: rida on need, mida soovisite. Parandage kõik curl-i teatatud sertifikaadivead enne TXT-kirje avaldamist.

Aruannete lugemine

Aruanded on ajavahemikku hõlmavad JSON-failid, mis sisaldavad kohaletoimetamise kokkuvõtet õnnestumiste ja ebaõnnestumiste arvuga. RFC rühmitab ebaõnnestumised läbirääkimise, poliitika, üldisteks ja ajutisteks tõrgeteks. Aruanded võivad saabuda pakituna (RFC määratleb application/tlsrpt+gzip), seega pakkige esmalt lahti:

gzip -dc report.json.gz | jq .

Väljade nimed on määratletud dokumendi RFC 8460 jaotises 4.4. Lugege kõigepealt kokkuvõtte arve, seejärel tõrgete kirjeid.

Aruanne, kus on palju õnnestumisi ja tõrkeid pole, on see, mida soovite näha. RFC märgib, et aruanne võib toimida südamelöögina, mis näitab, et TLS lepitakse kokku ootuspäraselt, ja stabiilne puhaste aruannete jada on teie tõend edasiminekuks. Tõrked, mis nimetavad üht teie enda MX-hosti, viitavad sertifikaadile või mx-mustrile, mida peate parandama. Üks saatja katkise tarkvaraveeruga on tema enda mure.

Järsk STARTTLS-tõrgete kasv, mida te ei oska mõne muudatusega seostada, tuleks anda edasi sellele, kes tegeleb intsidentidega, või meie intsidentidele reageerimise meeskonnale, kui teil sellist inimest pole.

Üleminek enforce-režiimile

Oodake, kuni aruanded on puhtad kõigi teie tavapäraste meilimustrite lõikes, sealhulgas vaiksete saatjate puhul, näiteks igakuised arveldussüsteemid. Seejärel muutke mode: testing väärtuseks mode: enforce ja muutke TXT-kirjes id, sest saatjad võrdlevad seda oma vahemällu salvestatud koopiaga, et teada saada, et midagi on muutunud.

Saatjad võivad poliitikat vahemälus hoida kuni max_age viimasest laadimisest, seega võib viga kauaks püsima jääda. Ka TXT-kirje kustutamine ei eemalda vahemällu salvestatud poliitikat, nagu RFC rõhutab. Eemaldamist käsitleb RFC 8461 jaotis 8.3 ja seda tasub lugeda enne, kui seda vaja läheb.

Kust alustada

1. Koostage loend oma kehtivatest MX-hostidest, sealhulgas pilveteenuse pakkuja omadest, ja veenduge, et igaüks esitab oma nimega sobiva kehtiva sertifikaadi.
2. Seadistage mta-sts host HTTPS-i kaudu ja serveerige poliitikafaili sisutüübiga text/plain ning mode: testing.
3. Avaldage üksainus _mta-sts TXT-kirje uue id-ga, seejärel tehke ülaltoodud dig- ja curl-kontrollid.
4. Avaldage _smtp._tls TXT-kirje, mis osutab eraldi postkastile või HTTPS-lõpp-punktile, ja kontrollige oma üldist seadistust meie e-posti turvalisuse kontrollijaga.
5. Vaadake aruandeid läbi vähemalt ühe täieliku äritsükli jooksul, sealhulgas kuu lõpu käivitused (enamikul organisatsioonidest on selleks kuu). Parandage kõik tõrked, mis on teie vastutusel, seejärel lülituge enforce-režiimi ja muutke id.