Կարճ ասած, MTA-STS-ը էլփոստի գաղտնալսումից (այսինքն՝ մարդ-միջին հարձակումներից՝ MitM) հետագա պաշտպանելու միջոց է, երբ դրանք փոխանցվում են փոստի սերվերների միջև: Այն մասամբ լուծում է էլփոստի արձանագրությունների ժառանգական ճարտարապետական ​​խնդիրները և նկարագրված է համեմատաբար վերջերս ստանդարտ RFC 8461-ում: Mail.ru-ն RuNet-ի առաջին խոշոր փոստային ծառայությունն է, որն իրականացնում է այս ստանդարտը: Իսկ կտրվածքի տակ ավելի մանրամասն նկարագրված է։

Ի՞նչ խնդիր է լուծում ՏԿԱԻՆ-ՀՊԾ-ն.

Պատմականորեն էլփոստի արձանագրությունները (SMTP, POP3, IMAP) տեղեկատվություն են փոխանցել հստակ տեքստով, ինչը հնարավորություն է տվել գաղտնալսել այն, օրինակ, կապի ալիք մուտք գործելիս:

Ինչպիսի՞ն է մի օգտագործողից մյուսին նամակ փոխանցելու մեխանիզմը.

Պատմականորեն MitM-ի հարձակումը հնարավոր էր բոլոր այն վայրերում, որտեղ փոստը շրջանառվում է:

RFC 8314-ը պահանջում է TLS-ի օգտագործում փոստի օգտագործողի հավելվածի (MUA) և փոստային սերվերի միջև: Եթե ​​ձեր սերվերը և ձեր օգտագործած փոստային հավելվածները համապատասխանում են RFC 8314-ին, ապա դուք (մեծ մասամբ) վերացրել եք օգտագործողի և փոստային սերվերների միջև Man-in-the-Middle հարձակումների հնարավորությունը:

Հետևելով ընդհանուր ընդունված գործելակերպին (ստանդարտացված RFC 8314-ով) վերացնում է օգտատիրոջ մոտ հարձակումը.

Mail.ru փոստի սերվերները համապատասխանում էին RFC 8314-ին նույնիսկ նախքան ստանդարտի ընդունումը, իրականում այն ​​պարզապես գրավում է արդեն ընդունված պրակտիկաները, և մենք կարիք չունեինք որևէ լրացուցիչ կարգավորելու: Բայց, եթե ձեր փոստային սերվերը դեռ թույլ է տալիս օգտվողներին օգտագործել անապահով արձանագրություններ, համոզվեք, որ կատարեք այս ստանդարտի առաջարկությունները, քանի որ Ամենայն հավանականությամբ, ձեր օգտատերերից առնվազն ոմանք աշխատում են փոստով առանց գաղտնագրման, նույնիսկ եթե դուք աջակցում եք դրան:

Փոստի հաճախորդը միշտ աշխատում է նույն կազմակերպության նույն փոստային սերվերի հետ: Եվ դուք կարող եք ստիպել բոլոր օգտատերերին միանալ անվտանգ եղանակով, այնուհետև տեխնիկապես անհնար դարձնել ոչ անվտանգ օգտատերերի միացումը (սա հենց այն է, ինչ պահանջում է RFC 8314): Սա երբեմն դժվար է, բայց իրագործելի: Փոստի սերվերների միջև երթևեկությունը դեռ ավելի բարդ է: Սերվերները պատկանում են տարբեր կազմակերպությունների և հաճախ օգտագործվում են «սահմանել և մոռանալ» ռեժիմով, ինչը անհնար է դարձնում միանգամից անվտանգ արձանագրության անցնելն առանց կապի խզման: SMTP-ն վաղուց տրամադրել է STARTTLS ընդլայնումը, որը թույլ է տալիս գաղտնագրումն աջակցող սերվերներին անցնել TLS: Բայց հարձակվողը, ով ունի երթևեկի վրա ազդելու ունակություն, կարող է «կտրել» այս հրամանի աջակցության մասին տեղեկատվությունը և ստիպել սերվերներին հաղորդակցվել՝ օգտագործելով պարզ տեքստային արձանագրություն (այսպես կոչված, իջեցում գրոհ): Նույն պատճառով, STARTTLS-ը սովորաբար չի ստուգում վկայագրի վավերականությունը (անվստահելի վկայականը կարող է պաշտպանել պասիվ հարձակումներից, և դա ավելի վատ չէ, քան պարզ տեքստով հաղորդագրություն ուղարկելը): Հետևաբար, STARTTLS-ը պաշտպանում է միայն պասիվ գաղտնալսումից:

MTA-STS-ը մասամբ վերացնում է նամակների գաղտնալսման խնդիրը փոստի սերվերների միջև, երբ հարձակվողը հնարավորություն ունի ակտիվորեն ազդելու տրաֆիկի վրա։ Եթե ​​ստացողի տիրույթը հրապարակում է MTA-STS քաղաքականություն, իսկ ուղարկողի սերվերը աջակցում է MTA-STS-ին, այն կուղարկի էլ.

Ինչու մասամբ: MTA-STS-ն աշխատում է միայն այն դեպքում, եթե երկու կողմերն էլ հոգացել են այս ստանդարտի ներդրման համար, և MTA-STS-ը չի պաշտպանում այն ​​սցենարներից, որոնցում հարձակվողը կարող է ստանալ տիրույթի վավեր վկայագիր հանրային CA-ներից մեկից:

Ինչպես է աշխատում ՏԿԱԻՆ-ՀՊԾ-ն

Ստացողը

1. Կազմաձևում է STARTTLS աջակցությունը վավեր վկայականով փոստի սերվերի վրա: 
2. Հրապարակում է MTA-STS քաղաքականությունը HTTPS-ի միջոցով, հրապարակման համար օգտագործվում են հատուկ mta-sts տիրույթ և հատուկ հայտնի ուղի, օրինակ. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Քաղաքականությունը պարունակում է փոստային սերվերների ցանկ (mx), որոնք իրավունք ունեն փոստ ստանալու այս տիրույթի համար:
3. Հրապարակում է հատուկ TXT գրառում _mta-sts DNS-ում՝ քաղաքականության տարբերակով: Երբ քաղաքականությունը փոխվում է, այս գրառումը պետք է թարմացվի (սա ուղարկողին ազդարարում է նորից հարցում անել քաղաքականությանը): Օրինակ, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Ուղարկող

Ուղարկողը խնդրում է _mta-sts DNS գրառումը, և եթե այն հասանելի է, ապա քաղաքականության հարցում է կատարում HTTPS-ի միջոցով (ստուգելով վկայագիրը): Ստացված քաղաքականությունը պահվում է քեշում (այն դեպքում, երբ հարձակվողը արգելափակում է մուտքը դեպի այն կամ կեղծում է DNS գրառումը):

Նամակ ուղարկելիս ստուգվում է, որ.

• սերվերը, որին ուղարկվում է փոստը, գտնվում է քաղաքականության մեջ.
• սերվերն ընդունում է նամակները՝ օգտագործելով TLS (STARTTLS) և ունի վավեր վկայագիր:

ՏԿԱԻՆ-ՀՊԾ-ի առավելությունները

MTA-STS-ն օգտագործում է տեխնոլոգիաներ, որոնք արդեն ներդրված են կազմակերպությունների մեծ մասում (SMTP+STARTTLS, HTTPS, DNS): Ստացողի կողմից իրականացման համար ստանդարտի համար հատուկ ծրագրային աջակցություն չի պահանջվում:

ՏԿԱԻՆ-ՀՊԾ-ի թերությունները

Անհրաժեշտ է վերահսկել վեբ և փոստային սերվերի վկայագրի վավերականությունը, անունների համապատասխանությունը և ժամանակին թարմացումը: Վկայագրի հետ կապված խնդիրների պատճառով փոստը չի կարող առաքվել:

Ուղարկողի կողմից պահանջվում է MTA-ն, որն աջակցում է MTA-STS քաղաքականությանը, ներկայումս MTA-STS-ը չի աջակցվում MTA-ի տուփից դուրս:

MTA-STS-ն օգտագործում է վստահելի արմատային CA-ների ցանկ:

MTA-STS-ը չի պաշտպանում հարձակումներից, որոնց դեպքում հարձակվողը օգտագործում է վավեր վկայական: Շատ դեպքերում, MitM-ը սերվերի մոտ ենթադրում է վկայագիր տրամադրելու հնարավորություն: Նման հարձակումը կարելի է հայտնաբերել վկայագրի թափանցիկության միջոցով: Ուստի, ընդհանուր առմամբ, ՏԿԱԻՆ-ը մեղմացնում է, բայց ամբողջությամբ չի վերացնում երթևեկության գաղտնալսման հնարավորությունը։

Վերջին երկու կետերը MTA-STS-ին դարձնում են ավելի քիչ անվտանգ, քան SMTP-ի համար մրցակցող DANE ստանդարտը (RFC 7672), բայց տեխնիկապես ավելի հուսալի, այսինքն. ՏԿԱԻՆ-ՀՊԾ-ի համար փոքր է հավանականությունը, որ նամակը չի առաքվի ստանդարտի ներդրման հետևանքով առաջացած տեխնիկական խնդիրների պատճառով։

Մրցակցող ստանդարտ - DANE

DANE-ն օգտագործում է DNSSEC՝ վկայականի տեղեկատվությունը հրապարակելու համար և չի պահանջում վստահություն արտաքին սերտիֆիկատների մարմիններին, ինչը շատ ավելի ապահով է: Բայց DNSSEC-ի օգտագործումը զգալիորեն ավելի հաճախ հանգեցնում է տեխնիկական խափանումների՝ հիմնվելով մի քանի տարվա օգտագործման վիճակագրության վրա (չնայած DNSSEC-ի և դրա տեխնիկական աջակցության հուսալիության մեջ ընդհանուր առմամբ դրական միտում կա): DANE-ը SMTP-ում ստացողի կողմից իրականացնելու համար DNSSEC-ի առկայությունը DNS գոտու համար պարտադիր է, և NSEC/NSEC3-ի ճիշտ աջակցությունը էական է DANE-ի համար, որի հետ կապված կան համակարգային խնդիրներ DNSSEC-ում:

Եթե ​​DNSSEC-ը ճիշտ կազմաձևված չէ, դա կարող է հանգեցնել փոստի առաքման ձախողումների, եթե ուղարկող կողմը աջակցում է DANE-ին, նույնիսկ եթե ստացող կողմը դրա մասին ոչինչ չգիտի: Հետևաբար, չնայած այն հանգամանքին, որ DANE-ն ավելի հին և անվտանգ ստանդարտ է և արդեն աջակցվում է ուղարկողի կողմից որոշ սերվերային ծրագրերում, իրականում դրա ներթափանցումը մնում է աննշան, շատ կազմակերպություններ պատրաստ չեն այն իրականացնել DNSSEC-ի ներդրման անհրաժեշտության պատճառով: սա զգալիորեն դանդաղեցրել է DANE-ի ներդրումը բոլոր այն տարիների ընթացքում, երբ գոյություն է ունեցել ստանդարտը:

DANE-ը և MTA-STS-ը չեն հակասում միմյանց և կարող են օգտագործվել միասին:

Ի՞նչ է MTA-STS-ի աջակցությունը Mail.ru Mail-ում:

Mail.ru-ն բավականին երկար ժամանակ հրապարակում է MTA-STS քաղաքականությունը բոլոր հիմնական տիրույթների համար: Ներկայումս մենք իրականացնում ենք ստանդարտի հաճախորդային մասը: Գրելու պահին քաղաքականությունը կիրառվում է չարգելափակման ռեժիմով (եթե առաքումն արգելափակված է քաղաքականության կողմից, նամակը կառաքվի «պահեստային» սերվերի միջոցով՝ առանց քաղաքականության կիրառման), ապա արգելափակման ռեժիմը կպարտադրվի մի փոքր մասի համար։ ելքային SMTP տրաֆիկի դեպքում աստիճանաբար տրաֆիկի 100%-ի համար կաջակցվի քաղաքականության կիրարկումը:

Էլ ո՞վ է աջակցում ստանդարտին:

Առայժմ ՏԿԱԻՆ-ՀՊԾ քաղաքականությունը հրապարակում է ակտիվ տիրույթների մոտավորապես 0.05%-ը, բայց, այնուամենայնիվ, դրանք արդեն պաշտպանում են փոստի մեծ ծավալը, քանի որ. Ստանդարտին աջակցում են հիմնական խաղացողները՝ Google-ը, Comcast-ը և մասամբ Verizon-ը (AOL, Yahoo): Շատ այլ փոստային ծառայություններ հայտարարել են, որ ստանդարտի աջակցությունը կիրականացվի մոտ ապագայում:

Ինչպե՞ս դա կազդի ինձ վրա:

Ոչ, քանի դեռ ձեր տիրույթը չի հրապարակում MTA-STS քաղաքականությունը: Եթե ​​դուք հրապարակեք քաղաքականությունը, ձեր փոստի սերվերի օգտատերերի նամակները ավելի լավ պաշտպանված կլինեն գաղտնալսումից:

Ինչպե՞ս կարող եմ իրականացնել ՏԿԱԻՆ-ՀՊԾ:

ՏԿԱԻՆ-ՀՊԾ աջակցություն ստացողի կողմից

Բավական է հրապարակել քաղաքականությունը HTTPS-ի միջոցով և գրառումներ DNS-ում, կարգավորել վավեր վկայական վստահված CA-ներից մեկից (Եկեք հնարավոր է գաղտնագրենք) STARTTLS-ի համար MTA-ում (STARTTLS-ն աջակցվում է բոլոր ժամանակակից MTA-ներում), ոչ մի հատուկ աջակցություն: Պահանջվում է ՏԿԱԻՆ.

Քայլ առ քայլ, այն ունի հետևյալ տեսքը.

1. Կարգավորեք STARTTLS-ը MTA-ում, որն օգտագործում եք (postfix, exim, sendmail, Microsoft Exchange և այլն):
2. Համոզվեք, որ դուք օգտագործում եք վավեր վկայագիր (տրված է վստահելի CA-ի կողմից, ժամկետանց, վկայագրի թեման համապատասխանում է ձեր տիրույթի համար փոստ առաքող MX գրառումին):
3. Կազմաձևեք TLS-RPT գրառումը, որի միջոցով կհանձնվեն քաղաքականության կիրառման հաշվետվությունները (ծառայությունների կողմից, որոնք աջակցում են TLS հաշվետվությունների ուղարկմանը): Օրինակ մուտք (օրինակ.com տիրույթի համար).

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

   Այս գրառումը նամակ ուղարկողներին հանձնարարում է ուղարկել SMTP-ում TLS-ի օգտագործման վերաբերյալ վիճակագրական հաշվետվություններ [email protected].

   Մի քանի օր վերահսկեք հաշվետվությունները՝ համոզվելու համար, որ սխալներ չկան:

4. Հրապարակեք 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), Mode-ը սահմանում է քաղաքականության կիրառման ռեժիմը, թեստավորում — փորձարկման ռեժիմ (քաղաքականությունը չի կիրառվում), ուժի մեջ — «մարտական» ռեժիմ։ Նախ հրապարակեք քաղաքականությունը ռեժիմով՝ թեստավորում, եթե թեստային ռեժիմում քաղաքականության հետ կապված խնդիրներ չկան, որոշ ժամանակ անց կարող եք անցնել ռեժիմին՝ ուժի մեջ մտնել:

   mx-ում նշված է բոլոր փոստի սերվերների ցանկը, որոնք կարող են փոստ ընդունել ձեր տիրույթի համար (յուրաքանչյուր սերվեր պետք է կազմաձևված լինի վկայական, որը համապատասխանում է mx-ում նշված անվանմանը): Max_age-ը սահմանում է քաղաքականության քեշավորման ժամանակը (երբ հիշվող քաղաքականությունը կկիրառվի, նույնիսկ եթե հարձակվողը արգելափակում է դրա առաքումը կամ փչացնում է DNS գրառումները քեշավորման ժամանակի ընթացքում, դուք կարող եք ազդարարել քաղաքականությունը նորից պահանջելու անհրաժեշտության մասին՝ փոխելով mta-sts DNS-ը: գրառում).

5. Հրապարակեք TXT գրառումը DNS-ում. 

   _mta-sts.example.com. TXT “v=STS1; id=someid;”
   

   id դաշտում կարող է օգտագործվել կամայական նույնացուցիչ (օրինակ՝ ժամանակի դրոշմ): երբ քաղաքականությունը փոխվում է, այն պետք է փոխվի, սա թույլ է տալիս ուղարկողներին հասկանալ, որ նրանք պետք է նորից պահանջեն պահված քաղաքականությունը (եթե նույնացուցիչը տարբերվում է քաղաքականությունից: պահված մեկը):

MTA-STS աջակցություն ուղարկողի կողմից

Առայժմ նրա հետ վատ է, քանի որ… թարմ ստանդարտ.

• Exim - ներկառուցված աջակցություն չկա, կա երրորդ կողմի սցենար https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - չկա ներկառուցված աջակցություն, կա երրորդ կողմի սցենար, որը մանրամասն նկարագրված է Habré-ում https://habr.com/en/post/424961/

Որպես վերջաբան «պարտադիր TLS»-ի մասին

Վերջերս կարգավորիչները ուշադրություն են դարձնում էլփոստի անվտանգությանը (և դա լավ է): Օրինակ, DMARC-ը պարտադիր է Միացյալ Նահանգների բոլոր պետական ​​մարմինների համար և ավելի ու ավելի է պահանջվում ֆինանսական հատվածում, երբ ստանդարտի ներթափանցումը կարգավորվող տարածքներում հասնում է 90%-ի: Այժմ որոշ կարգավորիչներ պահանջում են «պարտադիր TLS»-ի ներդրում առանձին տիրույթներով, սակայն «պարտադիր TLS»-ի ապահովման մեխանիզմը սահմանված չէ, և գործնականում այս պարամետրը հաճախ իրականացվում է այնպես, որ նույնիսկ նվազագույնը չի պաշտպանում իրական հարձակումներից, որոնք արդեն իսկ կան: նախատեսված է այնպիսի մեխանիզմներով, ինչպիսիք են DANE-ը կամ MTA-STS-ը:

Եթե ​​կարգավորիչը պահանջում է «պարտադիր TLS»-ի իրականացում առանձին տիրույթներով, խորհուրդ ենք տալիս դիտարկել MTA-STS-ը կամ դրա մասնակի անալոգը որպես ամենահարմար մեխանիզմ, այն վերացնում է յուրաքանչյուր տիրույթի համար առանձին-առանձին անվտանգ կարգավորումներ կատարելու անհրաժեշտությունը: Եթե ​​դուք դժվարություններ ունեք MTA-STS-ի հաճախորդի մասի իրականացման հարցում (մինչև արձանագրությունը լայնածավալ աջակցություն չստանա, նրանք, ամենայն հավանականությամբ, կստանան), մենք կարող ենք խորհուրդ տալ այս մոտեցումը.

1. Հրապարակեք MTA-STS քաղաքականությունը և/կամ DANE գրառումները (DANE-ն իմաստ ունի միայն այն դեպքում, եթե DNSSEC-ն արդեն միացված է ձեր տիրույթի համար, և MTA-STS-ն ամեն դեպքում), դա կպաշտպանի ձեր ուղղությամբ տրաֆիկը և կվերացնի փոստային այլ ծառայություններից հարցնելու անհրաժեշտությունը: ձեր տիրույթի համար պարտադիր TLS կարգավորելու համար, եթե փոստային ծառայությունն արդեն աջակցում է MTA-STS-ին և/կամ DANE-ին:
2. Խոշոր էլփոստի ծառայությունների համար ներդրեք MTA-STS-ի «անալոգը» յուրաքանչյուր տիրույթի համար առանձին տրանսպորտային կարգավորումների միջոցով, որը կֆիքսի փոստի փոխանցման համար օգտագործվող MX-ը և դրա համար կպահանջի TLS վկայագրի պարտադիր ստուգում: Եթե ​​տիրույթներն արդեն հրապարակում են MTA-STS քաղաքականությունը, դա, ամենայն հավանականությամբ, կարող է արվել առանց ցավի: Ինքնին տիրույթի համար պարտադիր TLS-ի միացումն առանց ռելեի ամրագրման և դրա համար վկայականի ստուգման անարդյունավետ է անվտանգության տեսանկյունից և ոչինչ չի ավելացնում գոյություն ունեցող STARTTLS մեխանիզմներին:

Source: www.habr.com