მოკლედ, MTA-STS არის გზა შემდგომი ელ.ფოსტის დასაცავად ფოსტის სერვერებს შორის გადაცემისას. ის ნაწილობრივ წყვეტს ელ.ფოსტის პროტოკოლების მემკვიდრეობით არქიტექტურულ პრობლემებს და აღწერილია შედარებით უახლეს სტანდარტში RFC 8461. Mail.ru არის პირველი ძირითადი საფოსტო სერვისი RuNet-ზე, რომელიც ამ სტანდარტს ახორციელებს. და ეს უფრო დეტალურად არის აღწერილი ჭრილის ქვეშ.

რა პრობლემას წყვეტს MTA-STS?

ისტორიულად, ელექტრონული ფოსტის პროტოკოლები (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-ს, ის გაგზავნის ელფოსტას მხოლოდ TLS კავშირის საშუალებით, მხოლოდ პოლიტიკით განსაზღვრულ სერვერებზე და მხოლოდ სერვერის სერთიფიკატის დადასტურებით.

რატომ ნაწილობრივ? MTA-STS მუშაობს მხოლოდ იმ შემთხვევაში, თუ ორივე მხარე ზრუნავს ამ სტანდარტის დანერგვაზე და MTA-STS არ იცავს სცენარებისგან, როდესაც თავდამსხმელს შეუძლია მიიღოს დომენის მოქმედი სერტიფიკატი ერთ-ერთი საჯარო CA-დან.

როგორ მუშაობს MTA-STS

მიმღები

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-ის უპირატესობები

MTA-STS იყენებს ტექნოლოგიებს, რომლებიც უკვე დანერგილია უმეტეს ორგანიზაციებში (SMTP+STARTTLS, HTTPS, DNS). მიმღების მხარეს განსახორციელებლად, სტანდარტის სპეციალური პროგრამული უზრუნველყოფის მხარდაჭერა არ არის საჭირო.

MTA-STS-ის უარყოფითი მხარეები

აუცილებელია ვებ და ფოსტის სერვერის სერტიფიკატის მოქმედების მონიტორინგი, სახელების შესაბამისობა და დროული განახლება. სერტიფიკატთან დაკავშირებული პრობლემები გამოიწვევს ფოსტის მიწოდებას.

გამგზავნის მხრიდან საჭიროა MTA MTA-STS პოლიტიკის მხარდაჭერით; ამჟამად MTA-STS მხარდაჭერილი არ არის MTA-ში.

MTA-STS იყენებს სანდო root CA-ების ჩამონათვალს.

MTA-STS არ იცავს თავდასხმებისგან, რომელშიც თავდამსხმელი იყენებს მოქმედ სერტიფიკატს. უმეტეს შემთხვევაში, MitM სერვერთან ახლოს გულისხმობს სერთიფიკატის გაცემის შესაძლებლობას. ასეთი თავდასხმის აღმოჩენა შესაძლებელია სერტიფიკატის გამჭვირვალობის გამოყენებით. ამიტომ, ზოგადად, MTA-STS ამსუბუქებს, მაგრამ სრულად არ გამორიცხავს მოძრაობის ჩარევის შესაძლებლობას.

ბოლო ორი წერტილი ხდის MTA-STS-ს ნაკლებ უსაფრთხოს, ვიდრე კონკურენტი DANE სტანდარტი SMTP-სთვის (RFC 7672), მაგრამ ტექნიკურად უფრო საიმედოს, ე.ი. MTA-STS-ისთვის არის დაბალი ალბათობა იმისა, რომ წერილი არ მიეწოდება სტანდარტის დანერგვით გამოწვეული ტექნიკური პრობლემების გამო.

კონკურენტი სტანდარტი - DANE

DANE იყენებს DNSSEC-ს სერტიფიკატის ინფორმაციის გამოსაქვეყნებლად და არ საჭიროებს ნდობას გარე სერტიფიკატის ორგანოების მიმართ, რაც ბევრად უფრო უსაფრთხოა. მაგრამ DNSSEC-ის გამოყენება მნიშვნელოვნად უფრო ხშირად იწვევს ტექნიკურ გაუმართაობას, რამდენიმე წლის გამოყენების სტატისტიკაზე დაყრდნობით (თუმცა ზოგადად დადებითი ტენდენციაა DNSSEC-ის სანდოობა და მისი ტექნიკური მხარდაჭერა). მიმღების მხარეს SMTP-ში DANE-ის დანერგვისთვის, 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% იქნება მხარდაჭერილი პოლიტიკის აღსრულება.

კიდევ ვინ უჭერს მხარს სტანდარტს?

ჯერჯერობით, MTA-STS პოლიტიკა აქვეყნებს აქტიური დომენების დაახლოებით 0.05%-ს, მაგრამ, მიუხედავად ამისა, ისინი უკვე იცავენ ფოსტის ტრაფიკის დიდ რაოდენობას, რადგან სტანდარტს მხარს უჭერს ძირითადი მოთამაშეები - Google, Comcast და ნაწილობრივ Verizon (AOL, Yahoo). ბევრმა სხვა საფოსტო სერვისმა გამოაცხადა, რომ სტანდარტის მხარდაჭერა უახლოეს მომავალში განხორციელდება.

როგორ იმოქმედებს ეს ჩემზე?

არა თუ თქვენი დომენი არ გამოაქვეყნებს MTA-STS პოლიტიკას. თუ თქვენ გამოაქვეყნებთ დებულებას, თქვენი ფოსტის სერვერის მომხმარებლების ელფოსტა უფრო დაცული იქნება ჩარევისგან.

როგორ განვახორციელო MTA-STS?

MTA-STS მხარდაჭერა მიმღების მხარეს

საკმარისია პოლიტიკის გამოქვეყნება HTTPS-ის საშუალებით და ჩანაწერები DNS-ში, დააკონფიგურიროთ მოქმედი სერტიფიკატი ერთ-ერთი სანდო CA-დან (მოდით დაშიფვრა შესაძლებელია) STARTTLS-ისთვის MTA-ში (STARTTLS მხარდაჭერილია ყველა თანამედროვე MTA-ში), არ არის სპეციალური მხარდაჭერა. 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]»

   ეს ჩანაწერი ავალებს ფოსტის გამგზავნებს, გაგზავნონ სტატისტიკური ანგარიშები TLS-ის გამოყენების შესახებ SMTP-ში [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), რეჟიმი ადგენს პოლიტიკის აპლიკაციის რეჟიმს, ტესტირება — ტესტის რეჟიმს (პოლიტიკა არ გამოიყენება), აღსრულება — „საბრძოლო“ რეჟიმი. ჯერ გამოაქვეყნეთ პოლიტიკა რეჟიმით: ტესტირება, თუ ტესტის რეჟიმში პოლიტიკასთან დაკავშირებული პრობლემები არ არის, გარკვეული პერიოდის შემდეგ შეგიძლიათ გადახვიდეთ რეჟიმზე: Enforce.

   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 მექანიზმებს.

წყარო: www.habr.com