กล่าวโดยย่อคือ MTA-STS เป็นวิธีการปกป้องอีเมลเพิ่มเติมจากการสกัดกั้น (เช่น การโจมตีแบบแทรกกลางหรือที่รู้จักกันในชื่อ MitM) เมื่อส่งระหว่างเมลเซิร์ฟเวอร์ ช่วยแก้ปัญหาทางสถาปัตยกรรมดั้งเดิมของโปรโตคอลอีเมลได้บางส่วน และอธิบายไว้ในมาตรฐาน RFC 8461 ที่ค่อนข้างใหม่ Mail.ru เป็นบริการเมลหลักบริการแรกบน RuNet ที่ใช้มาตรฐานนี้ และมีการอธิบายรายละเอียดเพิ่มเติมภายใต้การตัด

MTA-STS แก้ปัญหาอะไรได้บ้าง

ในอดีต โปรโตคอลอีเมล (SMTP, POP3, IMAP) ส่งข้อมูลในรูปแบบข้อความที่ชัดเจน ซึ่งทำให้สามารถดักข้อมูลได้ เช่น เมื่อเข้าถึงช่องทางการสื่อสาร

กลไกในการส่งจดหมายจากผู้ใช้รายหนึ่งไปยังอีกรายหนึ่งมีลักษณะอย่างไร:

ในอดีต การโจมตีแบบ MitM เกิดขึ้นได้ในทุกที่ที่มีการไหลเวียนของจดหมาย

RFC 8314 จำเป็นต้องใช้ TLS ระหว่างแอปพลิเคชันผู้ใช้เมล (MUA) และเซิร์ฟเวอร์เมล หากเซิร์ฟเวอร์และแอปพลิเคชันอีเมลที่คุณใช้เป็นไปตาม RFC 8314 แสดงว่าคุณ (ส่วนใหญ่) ได้ขจัดความเป็นไปได้ของการโจมตีแบบแทรกกลางระหว่างผู้ใช้และเซิร์ฟเวอร์อีเมลแล้ว

การปฏิบัติตามหลักปฏิบัติที่เป็นที่ยอมรับโดยทั่วไป (มาตรฐานโดย 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 ทำงานอย่างไร

ผู้รับ

กำหนดค่าการสนับสนุน STARTTLS ด้วยใบรับรองที่ถูกต้องบนเซิร์ฟเวอร์อีเมล
เผยแพร่นโยบาย MTA-STS ผ่าน HTTPS โดยจะใช้โดเมน mta-sts พิเศษและเส้นทางพิเศษที่รู้จักสำหรับการเผยแพร่ เช่น https://mta-sts.mail.ru/.well-known/mta-sts.txt. นโยบายประกอบด้วยรายการเซิร์ฟเวอร์อีเมล (mx) ที่มีสิทธิ์รับอีเมลสำหรับโดเมนนี้
เผยแพร่ระเบียน TXT พิเศษ _mta-sts ใน DNS พร้อมด้วยเวอร์ชันนโยบาย เมื่อนโยบายมีการเปลี่ยนแปลง รายการนี้จะต้องได้รับการอัปเดต (ซึ่งจะเป็นการส่งสัญญาณให้ผู้ส่งสอบถามนโยบายอีกครั้ง) ตัวอย่างเช่น, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

ผู้ส่ง

ผู้ส่งร้องขอบันทึก DNS _mta-sts และหากพร้อมใช้งาน ให้ส่งคำขอนโยบายผ่าน 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 และการสนับสนุนทางเทคนิคก็ตาม) หากต้องการใช้ 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% ของการรับส่งข้อมูล รองรับการบังคับใช้นโยบาย

มีใครสนับสนุนมาตรฐานนี้อีกบ้าง?

จนถึงตอนนี้ นโยบาย MTA-STS เผยแพร่ประมาณ 0.05% ของโดเมนที่ใช้งานอยู่ แต่อย่างไรก็ตาม นโยบายเหล่านี้ได้ปกป้องการรับส่งอีเมลจำนวนมากแล้ว เนื่องจาก มาตรฐานนี้ได้รับการสนับสนุนจากผู้เล่นรายใหญ่ - Google, Comcast และ Verizon บางส่วน (AOL, Yahoo) บริการไปรษณีย์อื่นๆ หลายแห่งได้ประกาศว่าจะมีการดำเนินการสนับสนุนมาตรฐานนี้ในอนาคตอันใกล้นี้

สิ่งนี้จะส่งผลต่อฉันอย่างไร?

ไม่เว้นแต่โดเมนของคุณจะเผยแพร่นโยบาย MTA-STS หากคุณเผยแพร่นโยบาย อีเมลสำหรับผู้ใช้เซิร์ฟเวอร์อีเมลของคุณจะได้รับการปกป้องจากการสกัดกั้นได้ดีขึ้น

ฉันจะใช้ MTA-STS ได้อย่างไร

รองรับ MTA-STS ทางฝั่งผู้รับ

การเผยแพร่นโยบายผ่าน HTTPS และบันทึกใน DNS กำหนดค่าใบรับรองที่ถูกต้องจาก CA ที่เชื่อถือได้ (ลองเข้ารหัสได้) สำหรับ STARTTLS ใน MTA (รองรับ STARTTLS ใน MTA สมัยใหม่ทั้งหมด) ก็เพียงพอแล้ว) ไม่มีการสนับสนุนพิเศษจาก จำเป็นต้องมี สทท.

ทีละขั้นตอนดูเหมือนว่านี้:

กำหนดค่า STARTTLS ใน MTA ที่คุณใช้ (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]»
```
รายการนี้แนะนำให้ผู้ส่งเมลส่งรายงานทางสถิติเกี่ยวกับการใช้งาน TLS ใน SMTP ไปที่ [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 บันทึก).
เผยแพร่บันทึก TXT ใน DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
ตัวระบุที่กำหนดเอง (เช่น การประทับเวลา) สามารถใช้ในช่องรหัสได้ เมื่อนโยบายเปลี่ยนแปลง ก็ควรเปลี่ยน ซึ่งจะทำให้ผู้ส่งเข้าใจว่าตนจำเป็นต้องขอนโยบายที่แคชไว้อีกครั้ง (หากตัวระบุแตกต่างจาก แคชอันหนึ่ง)

รองรับ 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 (จนกว่าโปรโตคอลจะได้รับการสนับสนุนอย่างกว้างขวาง มีแนวโน้มว่าจะเป็นเช่นนั้น) เราสามารถแนะนำแนวทางนี้ได้:

เผยแพร่นโยบาย MTA-STS และ/หรือบันทึก DANE (DANE จะเหมาะสมก็ต่อเมื่อ DNSSEC ได้รับการเปิดใช้งานสำหรับโดเมนของคุณแล้ว และ MTA-STS ไม่ว่าในกรณีใดก็ตาม) ซึ่งจะช่วยปกป้องการรับส่งข้อมูลในทิศทางของคุณ และไม่จำเป็นต้องถามบริการอีเมลอื่น ๆ เพื่อกำหนดค่า TLS บังคับสำหรับโดเมนของคุณ หากบริการอีเมลรองรับ MTA-STS และ/หรือ DANE อยู่แล้ว
สำหรับบริการอีเมลขนาดใหญ่ ให้ใช้ MTA-STS แบบ "อะนาล็อก" ผ่านการตั้งค่าการขนส่งแยกกันสำหรับแต่ละโดเมน ซึ่งจะแก้ไข MX ที่ใช้สำหรับส่งต่ออีเมล และจะต้องมีการตรวจสอบใบรับรอง TLS แบบบังคับ หากโดเมนเผยแพร่นโยบาย MTA-STS อยู่แล้ว การดำเนินการนี้ก็น่าจะดำเนินการได้อย่างง่ายดาย โดยตัวมันเอง การเปิดใช้งาน TLS บังคับสำหรับโดเมนโดยไม่ต้องแก้ไขการส่งต่อและการตรวจสอบใบรับรองสำหรับโดเมนนั้นจะไม่มีประสิทธิภาพจากมุมมองด้านความปลอดภัย และไม่ได้เพิ่มสิ่งใดในกลไก STARTTLS ที่มีอยู่

ที่มา: will.com

เมล Mail.ru เริ่มใช้นโยบาย MTA-STS ในโหมดทดสอบ