Қысқаша айтқанда, MTA-STS пошта серверлері арасында жіберілген кезде электрондық пошталарды ұстап қалудан (яғни, MitM деп аталатын ортадағы адам шабуылдары) одан әрі қорғаудың тәсілі болып табылады. Ол электрондық пошта хаттамаларының бұрынғы архитектуралық мәселелерін ішінара шешеді және салыстырмалы түрде жақында RFC 8461 стандартында сипатталған. Mail.ru – RuNet-те осы стандартты іске асыратын алғашқы ірі пошта қызметі. Және ол кесінді астында толығырақ сипатталған.
MTA-STS қандай мәселені шешеді?
Тарихи түрде электрондық пошта хаттамалары (SMTP, POP3, IMAP) ақпаратты анық мәтінде жіберді, бұл оны, мысалы, байланыс арнасына кіру кезінде ұстап алуға мүмкіндік берді.
Бір пайдаланушыдан екінші пайдаланушыға хатты жеткізу механизмі қалай көрінеді:
Тарихи түрде MitM шабуылы пошта айналымы бар барлық жерлерде мүмкін болды.
RFC 8314 пошта пайдаланушы қолданбасы (MUA) мен пошта сервері арасында TLS пайдалануды талап етеді. Серверіңіз және сіз пайдаланатын пошта қолданбалары RFC 8314 стандартымен үйлесімді болса, пайдаланушы мен пошта серверлері арасындағы Man-in-the-Middle шабуылдарының мүмкіндігін (негізінен) жойдыңыз.
Келесі жалпы қабылданған тәжірибелер (RFC 8314 стандарты бойынша стандартталған) пайдаланушының қасындағы шабуылды жояды:
Mail.ru пошта серверлері стандарт қабылданғанға дейін RFC 8314 стандартына сәйкес келді; шын мәнінде, ол жай ғана қабылданған тәжірибелерді түсіреді және бізге қосымша ештеңе конфигурациялаудың қажеті жоқ. Бірақ, егер сіздің пошта серверіңіз әлі де пайдаланушыларға қауіпті хаттамаларды пайдалануға мүмкіндік берсе, осы стандарттың ұсыныстарын міндетті түрде орындаңыз, себебі Мүмкін, кем дегенде кейбір пайдаланушылар поштамен шифрлаусыз жұмыс істейді, тіпті сіз оны қолдасаңыз да.
Пошта клиенті әрқашан бір ұйымның бір пошта серверімен жұмыс істейді. Сіз барлық пайдаланушыларды қауіпсіз түрде қосылуға мәжбүрлей аласыз, содан кейін қауіпсіз емес пайдаланушылардың қосылуын техникалық мүмкін емес ете аласыз (бұл дәл RFC 8314 талап ететін нәрсе). Бұл кейде қиын, бірақ орындалады. Пошта серверлері арасындағы трафик әлі де күрделірек. Серверлер әртүрлі ұйымдарға жатады және жиі «орнату және ұмыту» режимінде пайдаланылады, бұл қосылымды үзбей бірден қауіпсіз протоколға ауысуды мүмкін емес етеді. SMTP ұзақ уақыт бойы шифрлауды қолдайтын серверлерге TLS жүйесіне ауысуға мүмкіндік беретін STARTTLS кеңейтімін берді. Бірақ трафикке әсер ету мүмкіндігі бар шабуылдаушы осы пәрменді қолдау туралы ақпаратты «қиып» алады және серверлерді кәдімгі мәтіндік протоколды (төмендету шабуылы деп аталады) арқылы байланысуға мәжбүрлей алады. Дәл сол себепті STARTTLS әдетте сертификаттың жарамдылығын тексермейді (сенімсіз сертификат пассивті шабуылдардан қорғай алады және бұл анық мәтінде хабарлама жіберуден жаман емес). Сондықтан STARTTLS тек пассивті тыңдаудан қорғайды.
MTA-STS, шабуылдаушы трафикке белсенді әсер ету мүмкіндігіне ие болған кезде, пошта серверлері арасындағы хаттарды ұстап алу мәселесін ішінара жояды. Егер алушының домені MTA-STS саясатын жарияласа және жіберушінің сервері MTA-STS қолдаса, ол электрондық поштаны TLS қосылымы арқылы, тек саясатпен анықталған серверлерге ғана жібереді және тек сервер сертификатын растайды.
Неліктен ішінара? MTA-STS тек екі тарап осы стандартты енгізуге мұқият болған жағдайда ғана жұмыс істейді және MTA-STS шабуылдаушы жалпыға ортақ CA-лардың бірінен жарамды домен сертификатын ала алатын сценарийлерден қорғамайды.
MTA-STS қалай жұмыс істейді
Алушы
- Пошта серверінде жарамды сертификатпен STARTTLS қолдауын теңшейді.
- MTA-STS саясатын HTTPS арқылы жариялайды; жариялау үшін арнайы mta-sts домені және арнайы белгілі жол пайдаланылады, мысалы
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Саясат осы домен үшін поштаны алуға құқығы бар пошта серверлерінің (mx) тізімін қамтиды. - Саясат нұсқасымен DNS жүйесінде _mta-sts арнайы TXT жазбасын жариялайды. Саясат өзгерген кезде, бұл жазба жаңартылуы керек (бұл жіберушіге саясатты қайта сұрауға сигнал береді). Мысалы,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Жіберуші
Жіберуші _mta-sts DNS жазбасын сұрайды және ол қолжетімді болса, HTTPS арқылы саясат сұрауын жасайды (сертификатты тексеру). Нәтижедегі саясат кэштеледі (егер шабуылдаушы оған кіруді бұғаттаса немесе DNS жазбасын бұрмалаған жағдайда).
Поштаны жіберу кезінде мыналар тексеріледі:
- пошта жеткізілетін сервер саясатта болады;
- сервер TLS (STARTTLS) арқылы поштаны қабылдайды және жарамды сертификаты бар.
MTA-STS артықшылықтары
MTA-STS көптеген ұйымдарда енгізілген технологияларды пайдаланады (SMTP+STARTTLS, HTTPS, DNS). Алушы тарапынан іске асыру үшін стандартқа арнайы бағдарламалық қамтамасыз етуді қолдау қажет емес.
MTA-STS кемшіліктері
Веб және пошта сервері сертификатының жарамдылығын, атаулардың сәйкестігін және уақытылы жаңартылуын қадағалау қажет. Сертификатқа қатысты мәселелер поштаны жеткізу мүмкін болмауына әкеледі.
Жіберуші тарапынан MTA-STS саясаттарын қолдауы бар MTA қажет; қазіргі уақытта MTA-STS-ке MTA қорабынан тыс қолдау көрсетілмейді.
MTA-STS сенімді түбірлік CA тізімін пайдаланады.
MTA-STS шабуылдаушы жарамды сертификатты пайдаланатын шабуылдардан қорғамайды. Көп жағдайда сервердің жанындағы MitM сертификат беру мүмкіндігін білдіреді. Мұндай шабуылды сертификат мөлдірлігі арқылы анықтауға болады. Сондықтан, жалпы алғанда, MTA-STS трафикті тоқтату мүмкіндігін азайтады, бірақ толығымен жоймайды.
Соңғы екі тармақ MTA-STS-ті SMTP үшін бәсекелес DANE стандартына (RFC 7672) қарағанда қауіпсіз емес етеді, бірақ техникалық сенімдірек, яғни. MTA-STS үшін стандартты енгізуден туындаған техникалық ақауларға байланысты хаттың жеткізілмеу ықтималдығы төмен.
Бәсекелес стандарт – DANE
DANE сертификат туралы ақпаратты жариялау үшін DNSSEC пайдаланады және сыртқы сертификат органдарына сенім артуды қажет етпейді, бұл әлдеқайда қауіпсіз. Бірақ DNSSEC пайдалану бірнеше жылдардағы статистикаға негізделген техникалық ақауларға жиі әкеледі (дегенмен DNSSEC сенімділігінде және оның техникалық қолдауында жалпы оң үрдіс бар). Алушы жағында SMTP жүйесінде DANE енгізу үшін DNS аймағы үшін DNSSEC болуы міндетті және NSEC/NSEC3 үшін дұрыс қолдау DNSSEC жүйесінде жүйелік мәселелер бар DANE үшін өте маңызды.
DNSSEC дұрыс конфигурацияланбаған болса, жіберуші тарап DANE тілін қолдаса, тіпті қабылдаушы тарап бұл туралы ештеңе білмесе де, ол поштаны жеткізу сәтсіздігіне әкелуі мүмкін. Сондықтан, DANE ескірек және қауіпсіз стандарт болып табылады және жіберуші жағында кейбір серверлік бағдарламалық жасақтамада қазірдің өзінде қолдау көрсетілетініне қарамастан, оның енуі шамалы болып қалады, көптеген ұйымдар DNSSEC енгізу қажеттілігіне байланысты оны енгізуге дайын емес, бұл стандарт болған жылдар бойы DANE енгізуді айтарлықтай баяулатты.
DANE және MTA-STS бір-біріне қайшы келмейді және оларды бірге пайдалануға болады.
Mail.ru Mail қызметінде MTA-STS қолдауы неде?
Mail.ru біраз уақыттан бері барлық негізгі домендерге арналған MTA-STS саясатын жариялап келеді. Қазіргі уақытта стандарттың клиенттік бөлігін енгізудеміз. Жазу кезінде саясаттар бұғаттаусыз режимде қолданылады (егер жеткізу саясатпен бұғатталған болса, хат саясаттарды қолданбай «қосалқы» сервер арқылы жеткізіледі), содан кейін блоктау режимі шағын бөлікке мәжбүр болады. шығыс SMTP трафигі, бірте-бірте трафиктің 100% үшін ол Саясаттардың орындалуына қолдау көрсетіледі.
Стандартты тағы кім қолдайды?
Осы уақытқа дейін MTA-STS саясаттары белсенді домендердің шамамен 0.05% жариялайды, бірақ соған қарамастан олар пошта трафигінің үлкен көлемін қазірдің өзінде қорғайды, өйткені Стандартты негізгі ойыншылар - Google, Comcast және ішінара Verizon (AOL, Yahoo) қолдайды. Көптеген басқа пошта қызметтері жақын арада стандартқа қолдау көрсетілетінін хабарлады.
Бұл маған қалай әсер етеді?
Доменіңіз MTA-STS саясатын жарияламайынша. Саясатты жарияласаңыз, пошта серверіңіздің пайдаланушыларына арналған электрондық хаттар бөгелуден жақсырақ қорғалған болады.
MTA-STS қалай енгіземін?
Алушы тарапынан MTA-STS қолдауы
Саясатты HTTPS және DNS жазбалары арқылы жариялау, MTA жүйесіндегі STARTTLS үшін сенімді CA бірінің жарамды сертификатын конфигурациялау (шифрлауға болады) жеткілікті (STARTTLS барлық заманауи MTA-да қолдау көрсетеді), арнайы қолдау көрсетілмейді. MTA қажет.
Біртіндеп келесідей көрінеді:
- Қолданылатын MTA жүйесінде STARTTLS конфигурациялаңыз (postfix, exim, sendmail, Microsoft Exchange, т.б.).
- Жарамды сертификатты пайдаланып жатқаныңызға көз жеткізіңіз (сенімді CA берген, мерзімі аяқталмаған, сертификат тақырыбы доменіңізге поштаны жеткізетін MX жазбасына сәйкес келеді).
- Саясат қолданбасының есептері жеткізілетін TLS-RPT жазбасын конфигурациялаңыз (TLS есептерін жіберуді қолдайтын қызметтер арқылы). Мысал енгізу (example.com домені үшін):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Бұл жазба пошта жөнелтушілеріне SMTP жүйесінде TLS пайдалануы туралы статистикалық есептерді жіберуге нұсқау береді.
[email protected].Ешқандай қатенің жоқтығына көз жеткізу үшін есептерді бірнеше күн бақылаңыз.
- MTA-STS саясатын HTTPS арқылы жариялау. Саясат орын бойынша CRLF жолының терминаторлары бар мәтіндік файл ретінде жарияланады.
https://mta-sts.example.com/.well-known/mta-sts.txtМысал саясат:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Нұсқа өрісі саясаттың нұсқасын қамтиды (қазіргі уақытта
STSv1), Режим саясат қолданбасының режимін, тестілеу — сынақ режимін (саясат қолданылмайды), мәжбүрлеу — «жауынгерлік» режимін орнатады. Алдымен саясатты режиммен жариялаңыз: тестілеу, егер сынақ режимінде саясатта проблемалар болмаса, біраз уақыттан кейін режимге ауысуға болады: мәжбүрлеу.mx ішінде сіздің доменіңіз үшін поштаны қабылдай алатын барлық пошта серверлерінің тізімі көрсетілген (әр серверде mx ішінде көрсетілген атқа сәйкес конфигурацияланған сертификат болуы керек). Max_age саясаттың кэштеу уақытын көрсетеді (есте сақталатын саясат тіпті кэштеу уақытында шабуылдаушы оның жеткізілімін блоктаса немесе DNS жазбаларын бұзса да қолданылғаннан кейін, mta-sts DNS өзгерту арқылы саясатты қайта сұрау қажеттілігі туралы сигнал бере аласыз. жазба).
- DNS жүйесінде TXT жазбасын жариялау:
_mta-sts.example.com. TXT “v=STS1; id=someid;”Идентификатор өрісінде ерікті идентификаторды (мысалы, уақыт белгісі) пайдалануға болады; саясат өзгерген кезде ол өзгеруі керек, бұл жіберушілерге кэштелген саясатты қайта сұрау керек екенін түсінуге мүмкіндік береді (егер идентификатор басқа болса кэштелген).
Жіберуші жағында MTA-STS қолдауы
Әзірге оның жағдайы нашар, өйткені... жаңа стандарт.
- Exim - кірістірілген қолдау жоқ, үшінші тарап сценарийі бар
- Postfix - кірістірілген қолдау жоқ, Habré-де егжей-тегжейлі сипатталған үшінші тарап сценарийі бар
«Міндетті TLS» туралы кейінгі сөз ретінде
Соңғы уақытта реттеушілер электрондық поштаның қауіпсіздігіне назар аударды (және бұл жақсы нәрсе). Мысалы, DMARC Америка Құрама Штаттарындағы барлық мемлекеттік органдар үшін міндетті болып табылады және қаржылық секторда талап етілуде, стандарттың енуі реттелетін салаларда 90% жетеді. Енді кейбір реттеушілер жеке домендермен «міндетті TLS» енгізуді талап етеді, бірақ «міндетті TLS» қамтамасыз ету механизмі анықталмаған және іс жүзінде бұл параметр көбінесе қазірдің өзінде жасалған нақты шабуылдардан тіпті аз қорғамайтын жолмен жүзеге асырылады. DANE немесе MTA-STS сияқты механизмдерде қарастырылған.
Егер реттеуші бөлек домендері бар «міндетті TLS» енгізуді талап етсе, біз ең қолайлы механизм ретінде MTA-STS немесе оның ішінара аналогын қарастыруды ұсынамыз, ол әрбір домен үшін қауіпсіз параметрлерді бөлек жасау қажеттілігін жояды. Егер сізде MTA-STS клиенттік бөлігін енгізуде қиындықтар туындаса (хаттама кең таралған қолдауға ие болғанға дейін, олар, ең алдымен, болады), біз мына тәсілді ұсына аламыз:
- MTA-STS саясатын және/немесе DANE жазбаларын жариялау (DANE сіздің доменіңіз үшін DNSSEC әлдеқашан қосылған болса ғана мағынасы бар және кез келген жағдайда MTA-STS), бұл сіздің бағыттағы трафикті қорғайды және басқа пошта қызметтерін сұрау қажеттілігін жояды. пошта қызметі MTA-STS және/немесе DANE қолдаса, домен үшін міндетті TLS конфигурациялау үшін.
- Үлкен электрондық пошта қызметтері үшін MTA-STS «аналогын» әрбір домен үшін бөлек тасымалдау параметрлері арқылы енгізіңіз, ол поштаны жіберу үшін пайдаланылатын MX түзетеді және ол үшін TLS сертификатын міндетті түрде тексеруді талап етеді. Егер домендер MTA-STS саясатын жариялаған болса, мұны ауыртпалықсыз орындауға болады. Өздігінен домен үшін міндетті TLS-ті релені бекітпей және оның сертификатын тексермей қосу қауіпсіздік тұрғысынан тиімсіз және бар STARTTLS механизмдеріне ештеңе қоспайды.
Ақпарат көзі: www.habr.com