בקיצור, MTA-STS היא דרך להגן עוד יותר על מיילים מפני יירוט (כלומר, התקפות man-in-the-middle aka MitM) כאשר הם משודרים בין שרתי דואר. זה פותר חלקית את הבעיות הארכיטקטוניות הישנות של פרוטוקולי דואר אלקטרוני ומתואר בתקן החדש יחסית 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 אינו מגן מפני תרחישים בהם תוקף מסוגל לקבל אישור תחום תקף מאחד ה-CAs הציבוריים.

איך עובד 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;"

שׁוֹלֵחַ

השולח מבקש את רשומת ה-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 משתמש ברשימה של CAs שורש מהימנים.

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% מהדומיינים הפעילים, אך עם זאת, היא כבר מגנה על נפח גדול של תעבורת דואר, מכיוון התקן נתמך על ידי שחקנים גדולים - גוגל, קומקאסט ובחלקו Verizon (AOL, Yahoo). שירותי דואר רבים אחרים הודיעו כי תמיכה בתקן תיושם בעתיד הקרוב.

איך זה ישפיע עלי?

לא אלא אם הדומיין שלך מפרסם מדיניות MTA-STS. אם תפרסם את המדיניות, מיילים למשתמשים בשרת הדואר שלך יהיו מוגנים טוב יותר מפני יירוט.

איך אני מיישם MTA-STS?

תמיכת MTA-STS בצד הנמען

מספיק לפרסם את המדיניות באמצעות HTTPS ורשומות ב-DNS, להגדיר אישור תקף מאחד ה-CAs המהימנים (אפשר להצפין) עבור STARTTLS ב-MTA (STARTTLS נתמך בכל ה-MTA המודרני), אין תמיכה מיוחדת מה- נדרש MTA.

צעד אחר צעד, זה נראה כך:

1. הגדר את STARTTLS ב-MTA שבו אתה משתמש (postfix, exim, sendmail, Microsoft Exchange וכו').
2. ודא שאתה משתמש באישור חוקי (הונפק על ידי CA מהימן, לא פג תוקפו, נושא האישור תואם לרשומת ה-MX שמספקת דואר עבור הדומיין שלך).
3. הגדר רשומת TLS-RPT שדרכה יימסרו דוחות יישומי מדיניות (על ידי שירותים התומכים בשליחת דוחות TLS). ערך לדוגמה (עבור הדומיין example.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), מצב מגדיר את מצב אפליקציית המדיניות, בדיקה - מצב בדיקה (המדיניות אינה מיושמת), אכיפת - מצב "קרב". תחילה פרסם את המדיניות עם mode: testing, אם אין בעיות במדיניות במצב test, לאחר זמן מה ניתן לעבור למצב: enforce.

   ב-mx, מצוינת רשימה של כל שרתי הדואר שיכולים לקבל דואר עבור הדומיין שלך (לכל שרת חייב להיות מוגדר אישור התואם לשם שצוין ב-mx). Max_age מציין את זמן השמירה של המדיניות במטמון (ברגע שהמדיניות הזכורה תיושם גם אם התוקף יחסום את מסירתה או ישחית את רשומות ה-DNS במהלך זמן השמירה, תוכל לאותת על הצורך לבקש את המדיניות שוב על ידי שינוי ה-DNS של mta-sts תקליט).

5. פרסם רשומת 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 (עד שהפרוטוקול יקבל תמיכה נרחבת, סביר להניח שהם יצליחו), אנו יכולים להמליץ ​​על גישה זו:

1. פרסם מדיניות MTA-STS ו/או רשומות DANE (DANE הגיוני רק אם DNSSEC כבר מופעל עבור הדומיין שלך, ו-MTA-STS בכל מקרה), זה יגן על התנועה לכיוונך וימנע את הצורך לשאול שירותי דואר אחרים כדי להגדיר TLS חובה עבור הדומיין שלך אם שירות הדואר כבר תומך ב-MTA-STS ו/או DANE.
2. עבור שירותי דוא"ל גדולים, הטמיע "אנלוגי" של MTA-STS באמצעות הגדרות תעבורה נפרדות עבור כל תחום, אשר יתקן את ה-MX המשמש להעברת דואר וידרוש אימות חובה של אישור TLS עבורו. אם הדומיינים כבר מפרסמים מדיניות MTA-STS, סביר להניח שניתן לעשות זאת ללא כאבים. כשלעצמו, הפעלת TLS חובה לתחום ללא תיקון הממסר ואימות התעודה עבורו אינה יעילה מבחינה אבטחה ואינה מוסיפה דבר למנגנוני STARTTLS הקיימים.

מקור: www.habr.com