MTA-STS, DANE და TLS-RPT: TLS-ის სავალდებულო გახდომა ელფოსტისთვის

სერვერებს შორის ფოსტა ჩვეულებრივ დაშიფრულია, მაგრამ ამას არაფერი იძლევა გარანტიას. გამგზავნი სერვერი შენს MX-ს პორტ 25-ზე უკავშირდება, ხედავს, რომ STARTTLS შეთავაზებულია, და კავშირს აუმჯობესებს - თუ გზაში რაღაცამ ეს შეთავაზება არ მოაცილა, რა შემთხვევაშიც ის მხრებს იჩეჩავს და ღია ტექსტით აგზავნის. ის არც იმას ამოწმებს, რომ სერტიფიკატი, რომელსაც აჩვენებენ, შენს სერვერს ეკუთვნის. ეს ოპორტუნისტული TLS-ია: ის პასიურ მოსმენას აჩერებს და მეტს არაფერს. ამ ხარვეზს სამი სტანდარტი ხურავს. MTA-STS HTTPS-ით აქვეყნებს პოლიტიკას, რომელიც ამბობს: "ჩემი ფოსტის სერვერები ეს სახელებია და ისინი ყოველთვის ვალიდურ TLS-ს იყენებენ". DANE სერტიფიკატის ანაბეჭდს DNSSEC-ით ხელმოწერილ DNS-ში აქვეყნებს. TLS-RPT გამგზავნებს სთხოვს, შეგატყობინონ, როცა შენამდე TLS ვერ გამოვიდა. დომენების უმეტესობისთვის სწორი პირველი ნაბიჯი არის TLS-RPT პლუს MTA-STS testing რეჟიმში, რამდენიმე კვირის სუფთა ანგარიშების შემდეგ enforce-ზე გადასვლით; DANE ღირს, თუ შენი DNS ჰოსტი DNSSEC-ს სწორად აკეთებს.

როგორ მუშაობს STARTTLS ფოსტის სერვერებს შორის და სად ფუჭდება#

ორ სერვერს შორის SMTP სესია ღია ტექსტით იწყება. მიმღები სერვერი EHLO-ზე პასუხად თავის შესაძლებლობებს ჩამოთვლის, და თუ მათ შორის STARTTLS-ია, გამგზავნს შეუძლია გაუმჯობესება მოითხოვოს:

S: 220 mail.example.com ESMTPC: EHLO mx.sender.netS: 250-mail.example.comS: 250-SIZE 52428800S: 250-STARTTLSS: 250 ENHANCEDSTATUSCODESC: STARTTLSS: 220 2.0.0 Ready to start TLS

ამის შემდეგ ყველაფერი დაშიფრულია. სისუსტეები იმ ორ გადაწყვეტილებაშია, რომელსაც გამგზავნი იღებს:

• გააუმჯობესოს თუ არა. შესაძლებლობების სია ღია ტექსტით მოგზაურობს. გზაში მყოფ თავდამსხმელს - ან ცუდად მოქცეულ firewall-ს, რომელიც SMTP-ს "ამოწმებს", რაც რეალურად ხდება - შეუძლია 250-STARTTLS ხაზის მოცილება. გამგზავნი ხედავს სერვერს, რომელიც TLS-ს არ სთავაზობს, და ღია ტექსტით აწვდის, რადგან უარის თქმა ნიშნავდა ფოსტაზე უარის თქმას იმ სერვერების დიდი რაოდენობისთვის, რომლებიც მას მართლა არ უჭერს მხარს.
• ენდოს თუ არა სერტიფიკატს. TLS-ის დროსაც კი გამგზავნს არ აქვს საიმედო გზა, გაიგოს, რომელი სახელი უნდა ეწეროს სერტიფიკატზე. MX ჩანაწერი არაავთენტიფიცირებული DNS-დან მოვიდა, ამიტომ თავდამსხმელს, რომელსაც DNS-ის გაყალბება შეუძლია, გამგზავნის მიმართვა საკუთარ სერვერზე შეუძლია, საკუთარი ვალიდური სერტიფიკატით. ამიტომ გამგზავნების უმეტესობა ნებისმიერ სერტიფიკატს იღებს, თვითხელმოწერილისა და ვადაგასულის ჩათვლით.

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

MTA-STS: HTTPS-ით გამოქვეყნებული პოლიტიკა#

MTA-STS-ს (RFC 8461) ორი ნაწილი აქვს: DNS TXT ჩანაწერი, რომელიც ამბობს, რომ პოლიტიკა არსებობს, და თავად პოლიტიკა, რომელიც HTTPS-ით ფიქსირებული მისამართიდან მოიტანება. რადგან HTTPS ვებ სერტიფიკატების ჩვეულებრივ სისტემას იყენებს, პოლიტიკა ავთენტიფიცირებულია, მიუხედავად იმისა, რომ DNS ძიება არ არის.

გამგზავნი ეძებს _mta-sts.example.com-ს, პოულობს id-ს, მოაქვს https://mta-sts.example.com/.well-known/mta-sts.txt და პოლიტიკას max_age წამით ქეშირებს. ამის შემდეგ შენს დომენზე ყოველი მიწოდება უნდა მოხდეს პოლიტიკის შესაბამის MX ჰოსტზე, TLS-ით, სერტიფიკატით, რომელიც ამ ჰოსტის სახელისთვის ვალიდურია და საჯარო სერტიფიცირების ორგანომდე ჯაჭვით მიდის. enforce რეჟიმში გამგზავნი, რომელიც ამ პირობებს ვერ აკმაყოფილებს, არ აწვდის; წერილი მის რიგში ელოდება და თავიდან ცდიან.

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

MTA-STS პოლიტიკის გამოქვეყნება#

სამი რამ არის საჭირო: პოლიტიკის ფაილი, ვებ სერვერი, რომელიც მას ვალიდური სერტიფიკატით ემსახურება mta-sts.<your domain>-ზე, და TXT ჩანაწერი.

პოლიტიკის ფაილი:

version: STSv1mode: testingmx: mail.example.commax_age: 86400

TXT ჩანაწერი:

v=STSv1; id=20261008T120000

id არის ნებისმიერი სტრიქონი 32-მდე ასოთი და ციფრით. გამგზავნები მას ქეშირებულს ადარებენ და პოლიტიკას თავიდან მოიტანენ, როცა ის იცვლება, ამიტომ მოსახერხებელი არჩევანი დროის ნიშნულია. ყოველ ჯერზე, როცა პოლიტიკის ფაილს არედაქტირებ, id შეცვალე.

წესები, რომლებსაც სპეციფიკაცია მკაცრად აწესებს და რომლებიც გაფუჭებული დანერგვების უმეტესობას ხსნის:

1. პოლიტიკის ჰოსტს უნდა ჰქონდეს ვალიდური სერტიფიკატი mta-sts.example.com-ისთვის, გაცემული საჯარო ორგანოს მიერ. თვითხელმოწერილი არ გამოდგება; ნდობის მთელი საფუძველი ეს არის.
2. არანაირი გადამისამართება. გამგზავნებმა პოლიტიკის მოტანისას HTTP redirect-ს არ უნდა მიჰყვნენ. ვებ სერვერი, რომელიც /.well-known/...-ს სხვა გზაზე ან ჰოსტზე გადაამისამართებს, MTA-STS-ს ჩუმად აფუჭებს.
3. მიაწოდე როგორც `text/plain` 200 პასუხით.
4. ყოველი `mx` ხაზი უნდა ემთხვეოდეს შენს MX ჩანაწერებში არსებულ სახელებს, და თითოეულ ფოსტის სერვერზე სერტიფიკატი უნდა იყოს ვალიდური იმ სახელისთვის, რომელზეც MX მიუთითებს.

დაიწყე mode: testing-ით და მოკლე max_age-ით, მაგალითად ერთი დღით. Testing რეჟიმში გამგზავნები ნებისმიერ შემთხვევაში აწვდიან, მაგრამ წარუმატებლობებს TLS-RPT-ით გატყობინებენ. ორი-სამი კვირის ანგარიშების შემდეგ, რომლებიც მხოლოდ წარმატებებს აჩვენებს, გადადი enforce-ზე, გაზარდე max_age კვირამდე ან მეტამდე (604800) და შეცვალე id.

TLS-RPT: გაიგე, როცა TLS ფუჭდება#

TLS-RPT (RFC 8460) კიდევ ერთი TXT ჩანაწერია. ის გამგზავნებს სთხოვს, ყოველდღიურად გამოგიგზავნონ შეჯამება შენს დომენთან მათი TLS კავშირების შესახებ:

v=TLSRPTv1; rua=mailto:tls-reports@example.com

დიდი გამგზავნები, მათ შორის Google და Microsoft, ამ ანგარიშებს აგზავნიან. თითოეული gzip-ით შეკუმშული JSON დოკუმენტია, რომელიც ერთ დღეს მოიცავს: პოლიტიკას, რომელიც გამოიყენეს (MTA-STS, DANE ან არცერთი), წარმატებული სესიების რაოდენობას და წარუმატებლობების რაოდენობას ტიპების მიხედვით. წარუმატებლობის ტიპები საკმარისად კონკრეტულია, რომ მათზე იმოქმედო:

TLS-RPT ყველაფერზე ადრე გამოაქვეყნე, MTA-STS-ის გარეშეც კი. პოლიტიკის არქონის შემთხვევაშიც ანგარიშები გეუბნება, რამდენმა გამგზავნმა მოგაღწია TLS-ით, რაც სასარგებლო საწყისი წერტილია, და ისინი არაფერი ღირს. მათთვის ცალკე საფოსტო ყუთი გამოიყენე - ისინი ყოველდღე მოდის ყველა დიდი პროვაიდერისგან - და ან JSON წაიკითხე, ან რომელიმე უფასო ანგარიშების მნახველს მიაწოდე.

DANE: DNSSEC-ში მიმაგრებული სერტიფიკატები#

DANE SMTP-ისთვის (RFC 7672) იმავე მიზანს სხვა გზით აღწევს. HTTPS პოლიტიკის ნაცვლად აქვეყნებ TLSA ჩანაწერს, რომელიც ამბობს, რომელ სერტიფიკატს ან გასაღებს წარადგენს შენი ფოსტის სერვერი, და ჩანაწერი სანდოა, რადგან ზონა DNSSEC-ით არის ხელმოწერილი.

_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 (    8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d )

სამი რიცხვი არის usage, selector და matching type. 3 1 1 - "ზუსტად ეს საბოლოო გასაღები, მისი SHA-256 ჰეშით" - ფოსტისთვის გავრცელებული და რეკომენდებული ფორმაა: ის საერთოდ არცერთ სერტიფიცირების ორგანოზე არ არის დამოკიდებული, და თვითხელმოწერილი სერტიფიკატიც მისაღებია. ჰეში სერტიფიკატის საჯარო გასაღებისაა, რომლის გამოთვლაც სერტიფიკატის ფაილიდან შეგიძლია:

$ openssl x509 -in cert.pem -noout -pubkey \    | openssl pkey -pubin -outform DER \    | openssl dgst -sha256

DANE-ს ორი მკაცრი მოთხოვნა აქვს, და ისინი წყვეტს, შენთვის არის თუ არა:

• ზონა, რომელიც შენს `MX` ჰოსტის სახელებს შეიცავს, DNSSEC-ით უნდა იყოს ხელმოწერილი, ისევე როგორც შენი დომენის ზონა, რომ MX ძიება სანდო იყოს. თუ შენი DNS ჰოსტი DNSSEC-ს არ სთავაზობს, ან მის მართვაში დარწმუნებული არ ხარ, აქ გაჩერდი. გაფუჭებული DNSSEC ჯაჭვი DANE-ის გათიშვაზე უარესს აკეთებს - ვალიდაციის მქონე resolver-ები დომენის გადაწყვეტას საერთოდ წყვეტენ.
• გასაღების ცვლა წინასწარ უნდა დაიგეგმოს. რადგან ჩანაწერი გასაღებს ამაგრებს, სერტიფიკატის ახალი გასაღებით განახლება ჩანაწერის წინასწარ განახლების გარეშე აიძულებს ყველა DANE-ის მავალიდირებელ გამგზავნს, მიწოდებაზე უარი თქვას. ან განახლებისას გასაღები ხელახლა გამოიყენე (ACME კლიენტების უმეტესობას ამის ოფცია აქვს), ან ახალი გასაღების ჰეში ძველის გვერდით გამოაქვეყნე, დაელოდე ჩანაწერის TTL-ის ამოწურვას, შემდეგ სერტიფიკატი შეცვალე და ძველი ჰეში წაშალე.

DANE-ს ამოწმებენ, სხვებთან ერთად, Postfix და Exim, როცა ასეა დაყენებული, Stalwart გამავალი ფოსტისთვის და Microsoft-ის Exchange Online. Gmail ამის ნაცვლად MTA-STS-ს ეყრდნობა. სწორედ ამ გაყოფის გამო აქვეყნებს ბევრი ოპერატორი ორივეს.

MTA-STS თუ DANE

თუ მხოლოდ ერთის გაკეთება შეგიძლია, პატარა დომენისთვის MTA-STS უფრო მარტივი და უფრო ფართოდ აღიარებული არჩევანია. თუ შენი DNS ჰოსტი DNSSEC-ს ერთ checkbox-ად აქცევს და გასაღების ცვლაში დისციპლინირებული ხარ, დაამატე DANE. ისინი კონფლიქტის გარეშე თანაარსებობენ, და TLS-RPT ორივეზე ანგარიშს აგზავნის.

გამგზავნის მხარე: შენი სერვერი და სხვა დომენები#

ყველაფერი ზემოთ ნათქვამი იცავს ფოსტას, რომელიც შენ გეგზავნება. შენი საკუთარი სერვერი, როცა აგზავნის, იგივე გადაწყვეტილებებს იღებს სხვა დომენების შესახებ. Stalwart გამავალი ფოსტის მიწოდებისას MTA-STS პოლიტიკებსა და DANE ჩანაწერებს ამოწმებს, და ორივე ვებ ადმინში მიწოდების თითოეული სტრატეგიისთვის კონფიგურირებადია. ნაგულისხმევი პარამეტრები მათ არასავალდებულოდ განიხილავს: გამოქვეყნებული და ვალიდური პოლიტიკა გამოიყენება, მაგრამ დომენი, რომლის პოლიტიკის მოტანა ან ვალიდაცია ვერ ხერხდება, ფოსტას მაინც იღებს. რომელიმეს გლობალურად "require"-ზე დაყენება აიძულებდა შენს სერვერს, უარი ეთქვა მიწოდებაზე იმ მრავალი დომენისთვის, რომლებიც არცერთს არ აქვეყნებს, და ეს ის არ არის, რაც გინდა. ნაგულისხმევი პარამეტრები დატოვე, თუ არ გყავს კონკრეტული პარტნიორი დომენი, სადაც დაშიფვრა უნდა იყოს გარანტირებული, და ეს ამ დომენისთვის ცალკე წესით მოაგვარე.

როგორ გააკეთო ეს RE:NODE-ის ფოსტის სერვერით#

Mail Server ხაზზე მუშაობს Stalwart, და აქ ნახსენები DNS ჩანაწერები - TXT MTA-STS-ისა და TLS-RPT-ისთვის, TLSA DANE-ისთვის - შენ უნდა დაამატო იქ, სადაც შენი DNS-ია დაჰოსტილი, ისევე როგორც MX, SPF, DKIM და DMARC ჩანაწერები. მხარდაჭერა პორტ 25-ს სერვერზე გადაამისამართებს, რომ მან ინტერნეტიდან ფოსტა მიიღოს, და სწორედ ამ პორტს ამოწმებენ გამგზავნები, როცა შენს პოლიტიკას იყენებენ, ამიტომ რამის გამოქვეყნებამდე დარწმუნდი, რომ იქ წარდგენილი სერტიფიკატი მოიცავს სახელს, რომელზეც შენი MX მიუთითებს.

MTA-STS პოლიტიკის ფაილს სჭირდება ვებ ჰოსტი ვალიდური სერტიფიკატით mta-sts.example.com-ზე. ნებისმიერი სტატიკური ჰოსტი გამოდგება. ვებ ჰოსტინგის გეგმაზე mta-sts.example.com-ის A ჩანაწერი მიმართე proxy სლოტისთვის ნაჩვენებ მისამართზე, და სერტიფიკატი ავტომატურად გაიცემა და განახლდება; პოლიტიკა ერთი ტექსტური ფაილია .well-known-ში. შეამოწმე, რომ საიტის კონფიგურაციაში არაფერი გადაამისამართებს ამ გზას.

სამუშაოს თანმიმდევრობა, რომელიც ფოსტას არ კარგავს#

ეს ჩანაწერები იმ ჩანაწერებს ეფუძნება, რომლებიც ყველა საფოსტო დომენს სჭირდება, ამიტომ ჯერ საფუძველი შეამოწმე. SPF, DKIM და DMARC წყვეტს, დაიჯერებენ თუ არა შენს ფოსტას; MX ჩანაწერები წყვეტს, სად მიდის ფოსტა. TLS პოლიტიკა მხოლოდ იმას აღწერს, როგორ აღწევს ის იქამდე, და არასწორ MX-ზე დაწერილი პოლიტიკა მის არქონაზე უარესია.

1. გაასწორე სერტიფიკატი პორტ 25-ზე. ის უნდა იყოს ვალიდური, ვადიანი და მოიცავდეს ყველა სახელს, რომელზეც შენი MX ჩანაწერები მიუთითებს. სანამ ეს ასე არ იქნება, ყოველი მომდევნო ნაბიჯი წარუმატებლობებს გაჩვენებს.
2. გამოაქვეყნე TLS-RPT. შეაგროვე ერთი კვირის ანგარიშები საერთოდ პოლიტიკის გარეშე, რომ ნახო, როგორ გაღწევენ გამგზავნები ამჟამად.
3. გამოაქვეყნე MTA-STS testing რეჟიმში ერთდღიანი max_age-ით. წაიკითხე ორი-სამი კვირის ანგარიშები.
4. გადადი enforce-ზე, გაზარდე max_age, შეცვალე id. ანგარიშების კითხვა განაგრძე; განახლება, რომელიც სამ თვეში ჩავარდება, იქ პირველად გამოჩნდება.
5. DANE დაამატე მხოლოდ მაშინ, თუ შენი DNS DNSSEC-ით არის ხელმოწერილი და გასაღების ცვლის წერილობითი გეგმა გაქვს.

ჩვევა იგივეა, რაც DMARC-ის დანერგვას უსაფრთხოს ხდის - გამოაქვეყნე ანგარიშების რეჟიმში, წაიკითხე, რა ბრუნდება, შემდეგ აამოქმედე - და DMARC ანგარიშები და პოლიტიკის დანერგვა ამას უფრო დეტალურად აღწერს. აგრეგირებული ანგარიშები ერთადერთი უკუკავშირია, რომელსაც სხვების ფოსტის სერვერებიდან იღებ, და ისინი იმ ცალკე საფოსტო ყუთად ღირს, რომელიც მათ სჭირდებათ.

შენი დაყენების ტესტირება#

ნებისმიერი მანქანიდან, სადაც dig, curl და openssl არის:

$ dig +short TXT _mta-sts.example.com$ curl -sv https://mta-sts.example.com/.well-known/mta-sts.txt$ dig +short TXT _smtp._tls.example.com$ dig +short MX example.com$ openssl s_client -connect mail.example.com:25 -starttls smtp \    -servername mail.example.com </dev/null | openssl x509 -noout -subject -dates$ dig +dnssec +short TLSA _25._tcp.mail.example.com

შეამოწმე, რომ პოლიტიკის მოტანა 200-ს აბრუნებს გადამისამართების გარეშე, რომ mx ხაზები MX პასუხს ემთხვევა, რომ პორტ 25-ზე სერტიფიკატი MX ჰოსტს ასახელებს და ვადიანია, და - DANE-ისთვის - რომ TLSA პასუხი გასაღების ჰეშს ემთხვევა და პასუხი ვალიდირებულია. შენი დომენი და მისი სერტიფიკატი აღწერს სერტიფიკატის განახლებას, სადაც ასეთი დაყენებების უმეტესობა ბოლოს და ბოლოს ფუჭდება.

FAQ#

დაშიფრულია ჩემი ფოსტა ამ ყველაფრის გარეშე?

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

შიფრავს MTA-STS ფოსტას, რომელსაც სხვებს ვუგზავნი?

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

რა ხდება, თუ enforce რეჟიმში ჩემი პოლიტიკა არასწორია?

გამგზავნები, რომლებიც მას პატივს სცემენ, მიწოდებაზე უარს ამბობენ და ფოსტას რიგში ინახავენ, ჩვეულებრივ რამდენიმე დღით, სანამ მას თავდაპირველ გამგზავნს bounce-ით დაუბრუნებენ. შენამდე არაფერი აღწევს და არაფერი გეუბნება, TLS-RPT ანგარიშების გარდა. სწორედ ამიტომ მოდის testing რეჟიმი პირველი და სწორედ ამიტომ სჭირდება პოლიტიკის ცვლილებას ახალი id.

მჭირდება DNSSEC MTA-STS-ისთვის?

არა. MTA-STS შეიქმნა DNSSEC-ის არმქონე დომენებისთვის; მისი ნდობა პოლიტიკის ჰოსტზე არსებული HTTPS სერტიფიკატიდან მოდის. DNSSEC-ს DANE მოითხოვს.

რამდენი უნდა იყოს max_age?

ტესტირებისას ერთი დღე, რომ შეცდომებს ვადა სწრაფად გაუვიდეს. როცა enforce რეჟიმში ხარ და ყველაფერი სტაბილურია, კვირიდან თვემდე ჩვეულებრივია, და უფრო გრძელი უკეთეს დაცვას იძლევა თავდამსხმელისგან, რომელიც პოლიტიკის მოტანას ბლოკავს. გახსოვდეს, რომ გრძელი max_age ასევე ნიშნავს ხანგრძლივ ლოდინს, როცა ფოსტის სერვერებს ცვლი.