MTA-STS ва TLS-RPT: почта шифрланишини мажбурлаш

Почта серверлари бир-бирига хат узатганда одатда STARTTLS орқали шифрланган уланиш ўрнатишга ҳаракат қилади. Лекин бу шифрлаш ихтиёрий: агар уланиш ўртасида турган кимдир STARTTLS таклифини олиб ташласа ёки сохта сертификат кўрсатса, юборувчи сервер кўпинча хатни шифрсиз юбораверади. Натижада шартномалар, ҳисоб-фактуралар ва шахсий маълумотлар очиқ матнда узатилиши мумкин. MTA-STS стандарти бу бўшлиқни ёпади: у юборувчи серверларга доменингизга хатни фақат ҳақиқий сертификатли шифрланган уланиш орқали етказиш кераклигини айтади. TLS-RPT эса бу жараёнда юз берган муаммолар ҳақида сизга ҳисобот юборади.

MTA-STS қандай ишлайди

MTA-STS икки қисмдан иборат. Биринчиси DNS'даги кичик TXT ёзув бўлиб, у доменда сиёсат борлигини ва унинг жорий версиясини билдиради. Иккинчиси HTTPS орқали жойлаштирилган сиёсат файли бўлиб, унда қайси MX серверлар қабул қилиниши ва сиёсат қанчалик қатъий эканлиги ёзилади. Юборувчи сервер аввал DNS ёзувини кўради, кейин сиёсат файлини юклаб олади ва уни маълум муддат кешда сақлайди. Шундан кейин у доменингизга хат юборишда MX сервернинг сертификати ҳақиқий ва номи мос эканини текширади.

Сиёсат файлининг айнан HTTPS орқали олиниши муҳим. DNS жавобини сохталаштириш нисбатан осон, лекин ҳақиқий сертификат билан ҳимояланган веб-саҳифани сохталаштириш анча қийин. Шу сабабли MTA-STS DNSSEC талаб қилмайди ва кўпчилик доменлар учун амалда жорий этиш мумкин бўлган ҳимоя ҳисобланади.

Бошлашдан олдин MX серверларни текшириш

MTA-STS фақат MX серверларингиз тўғри сертификатга эга бўлгандагина ишлайди. Сертификат ишончли марказ томонидан берилган, муддати ўтмаган ва MX ёзувидаги номга мос бўлиши керак. Ўз-ўзидан имзоланган сертификат ёки бошқа номга берилган сертификат билан enforce режимини ёқсангиз, хатлар етказилмай қолади. Текшириш учун аввал MX ёзувларини олинг, кейин ҳар бир сервер билан STARTTLS уланишини синаб кўринг:

dig +short MX example.uz
openssl s_client -starttls smtp -connect mail.example.uz:25 -servername mail.example.uz </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Натижада сертификат кимга берилгани, уни ким чиқаргани ва амал қилиш муддати кўринади. Агар почтангиз хостинг провайдери серверларида жойлашган бўлса, MX номи ва сертификат ҳолатини провайдердан аниқланг, чунки сиёсат файлида айнан ўша ном кўрсатилади. Баъзи тармоқларда чиқувчи 25-порт ёпиқ бўлади, бундай ҳолда текширувни сервер ёки бошқа тармоқдан бажаринг.

Сиёсат файлини жойлаштириш

Сиёсат файли mta-sts субдоменида, аниқ белгиланган йўлда туриши шарт: https://mta-sts.example.uz/.well-known/mta-sts.txt. Бунинг учун субдомен учун DNS ёзуви ва ҳақиқий SSL сертификати керак. Файл мазмуни оддий матн бўлиб, ҳар бир қаторда битта параметр ёзилади:

version: STSv1
mode: testing
mx: mail.example.uz
mx: mail2.example.uz
max_age: 604800

mode уч қийматга эга: testing режимида юборувчилар муаммони фақат ҳисоботда билдиради ва хатни барибир етказади, enforce режимида шифрлаш талаблари бажарилмаса хат юборилмайди, none эса сиёсатни бекор қилиш учун ишлатилади. max_age сонияларда ёзилади ва сиёсат қанча вақт кешда сақланишини белгилайди, юқоридаги қиймат бир ҳафтага тенг. Агар MX номлари умумий домен остида бўлса, mx: *.example.uz каби юлдузча шаблонидан ҳам фойдаланиш мумкин.

Агар субдомен Nginx серверида хизмат қилса, файлни бериш учун қуйидаги блок етарли:

server {
    listen 443 ssl;
    server_name mta-sts.example.uz;
    ssl_certificate     /etc/letsencrypt/live/mta-sts.example.uz/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.example.uz/privkey.pem;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        alias /var/www/mta-sts/mta-sts.txt;
    }
}

Оддий хостингда эса mta-sts субдоменини алоҳида сайт сифатида яратиб, унинг папкасида .well-known каталогини очиш ва файлни у ерга жойлаштириш кифоя.

DNS ёзувлари: MTA-STS ва TLS-RPT

Файл тайёр бўлгач, иккита TXT ёзув қўшилади. Биринчиси MTA-STS сиёсати борлигини эълон қилади ва унда id қиймати туради. Бу қиймат сиёсат версиясининг белгиси: файлни ҳар сафар ўзгартирганингизда id ни ҳам янгилашингиз керак, акс ҳолда юборувчилар эски кешланган сиёсатдан фойдаланишда давом этади. Одатда id сифатида сана ва вақт ёзилади. Иккинчи ёзув TLS-RPT учун бўлиб, ҳисоботлар қайси манзилга юборилишини кўрсатади.

_mta-sts.example.uz.    IN  TXT  "v=STSv1; id=20261104T090000"
_smtp._tls.example.uz.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.uz"

Ҳаммасини қуйидаги буйруқлар билан текширинг. Сиёсат файли тўғри очилиши ва DNS ёзувлари кўриниши керак:

curl -s https://mta-sts.example.uz/.well-known/mta-sts.txt
dig +short TXT _mta-sts.example.uz
dig +short TXT _smtp._tls.example.uz

TLS-RPT ҳисоботларини ўқиш

TLS-RPT'ни қўллаб-қувватловчи провайдерлар одатда кунига бир марта JSON форматидаги ҳисобот юборади. Унда сизнинг доменингизга нечта муваффақиятли шифрланган сеанс ўрнатилгани ва нечтаси муваффақиятсиз бўлгани, муваффақиятсизлик сабаби билан бирга кўрсатилади. Сабаблар орасида сертификат муддати ўтгани, ном мос келмагани ёки STARTTLS умуман таклиф қилинмагани бўлиши мумкин. testing режимида айнан шу ҳисоботлар сизга enforce га ўтиш хавфсизми ёки йўқлигини кўрсатади. Бир-икки ҳафта давомида хатоликлар бўлмаса, сиёсат файлида режимни ўзгартириб, id ни янгилаш мумкин.

Мисол: Тошкентдаги аудиторлик фирмаси

Тошкентдаги аудиторлик фирмаси мижозларидан молиявий ҳисоботлар ва шартномаларни электрон почта орқали қабул қилади. Фирма раҳбарияти бу маълумотлар узатиш пайтида шифрланмай қолиши мумкинлигидан хавотирда. Администратор аввал MX серверда ҳақиқий сертификат борлигини текширади, кейин mta-sts субдоменини яратади, сиёсат файлини testing режимида жойлаштиради ва иккала TXT ёзувни қўшади. Икки ҳафта давомида келган TLS-RPT ҳисоботларида муваффақиятсиз сеанслар йўқ. Шундан кейин режим enforce га ўзгартирилади, id янгиланади ва энди сиёсатни қўллаб-қувватловчи провайдерлар фирмага хатни фақат ҳимояланган уланиш орқали етказади.

Эҳтиёт бўлиш керак бўлган ҳолатлар

Энг кўп учрайдиган хато бу MX серверни алмаштирганда сиёсат файлини янгилашни унутишдир. Агар янги MX номи файлда бўлмаса ва режим enforce бўлса, юборувчилар хатни етказа олмайди. Шунинг учун почтани бошқа серверга кўчиришдан олдин янги номни файлга қўшинг, id ни янгиланг ва кеш муддати ўтишини кутинг. Иккинчи хато mta-sts субдоменидаги сертификат муддати ўтиб кетиши: бунда янги сиёсат юклаб олинмайди. Автоматик янгиланадиган сертификат бу муаммони олдини олади. sayt.uz хостингида субдоменлар учун бепул Let's Encrypt сертификати автоматик янгиланади, шунинг учун mta-sts субдомени сертификати ҳақида алоҳида қайғуриш шарт эмас.