Singkatnya, MTA-STS adalah cara tambahan untuk melindungi email dari intersepsi (yaitu, serangan penyerang-di-tengah alias MitM) saat mereka ditransfer antar server email. Ini sebagian memecahkan masalah arsitektural yang diwariskan dari protokol email dan dijelaskan dalam standar RFC 8461 yang relatif baru. Mail.ru Mail adalah layanan pos besar pertama di Internet Rusia yang menerapkan standar ini. Dan itu dijelaskan lebih detail di bawah potongan.

Masalah apa yang diselesaikan MTA-STS?

Secara historis, protokol email (SMTP, POP3, IMAP) mengirimkan informasi dengan jelas, yang memungkinkannya untuk disadap, misalnya, saat mengakses saluran komunikasi.



Seperti apa mekanisme pengiriman surat dari satu pengguna ke pengguna lain:







Secara historis, serangan MitM mungkin terjadi di semua tempat di mana email masuk.



RFC 8314 memerlukan penggunaan TLS wajib antara program email pengguna (MUA) dan server email. Jika server dan aplikasi email yang Anda gunakan sesuai dengan RFC 8314, maka Anda (sebagian besar) telah menghilangkan kemungkinan serangan Man-in-the-Middle antara pengguna dan server email.



Kepatuhan pada praktik umum (distandarisasi oleh RFC 8314) menghilangkan serangan dekat-pengguna:







Server email Mail.ru mematuhi RFC 8314 bahkan sebelum standar diadopsi, pada kenyataannya, itu hanya menangkap praktik yang sudah diterima, dan kami tidak perlu mengkonfigurasi apa pun lebih jauh. Namun, jika server email Anda masih mengizinkan pengguna melalui protokol yang tidak aman, pastikan untuk menerapkan rekomendasi standar ini, karena kemungkinan besar setidaknya beberapa pengguna Anda bekerja dengan email tanpa enkripsi, meskipun Anda mendukungnya.



Klien email selalu bekerja dengan server email yang sama dari organisasi yang sama. Dan Anda dapat memaksa semua pengguna untuk terhubung dengan cara yang aman, dan kemudian membuatnya secara teknis tidak mungkin untuk terhubung secara tidak aman (inilah yang dibutuhkan RFC 8314). Terkadang sulit, tetapi dapat disadari. Lalu lintas antar server email masih lebih rumit. Server milik organisasi yang berbeda dan sering digunakan dalam mode "set and forget", yang membuat tidak mungkin untuk beralih ke protokol aman sekaligus tanpa memutus konektivitas. SMTP telah lama menyediakan ekstensi STARTTLS, yang memungkinkan server yang mendukung enkripsi untuk beralih ke TLS. Tapi penyerang yang memiliki kemampuan untuk mempengaruhi lalu lintasdapat "memotong" informasi tentang dukungan perintah ini dan memaksa server untuk berkomunikasi menggunakan protokol teks biasa (yang disebut serangan downgrade - serangan untuk menurunkan versi protokol). Untuk alasan yang sama, untuk STARTTLS, kepatuhan sertifikat biasanya tidak dicentang (sertifikat yang tidak tepercaya dapat melindungi dari serangan pasif, dan ini tidak lebih buruk daripada mengirim email dalam teks biasa). Oleh karena itu, STARTTLS hanya melindungi dari penyadapan pasif.



MTA-STS secara parsial menghilangkan masalah intersepsi pesan antar server email, saat penyerang memiliki kemampuan untuk secara aktif memengaruhi lalu lintas. Jika domain penerima menerbitkan kebijakan MTA-STS dan server pengirim mendukung MTA-STS, domain penerima hanya akan mengirim email melalui koneksi TLS, hanya ke server yang ditentukan oleh kebijakan, dan hanya dengan sertifikat server yang diverifikasi.



Mengapa sebagian? MTA-STS hanya berfungsi jika kedua pihak telah menerapkan standar ini, dan MTA-STS tidak melindungi dari skenario di mana penyerang memiliki kesempatan untuk mendapatkan sertifikat domain yang valid di salah satu CA publik.

Bagaimana MTA-STS Bekerja

Penerima

1. Mengonfigurasi dukungan untuk STARTTLS dengan sertifikat yang valid di server email. 
2. Menerbitkan kebijakan MTA-STS melalui HTTPS, domain mta-sts khusus dan jalur khusus terkenal, misalnya, digunakan untuk penerbitan https://mta-sts.mail.ru/.well-known/mta-sts.txt. Kebijakan berisi daftar server email (mx) yang berhak menerima email untuk domain ini.
3. Menerbitkan data TXT _mta-sts khusus di DNS dengan versi kebijakan. Saat kebijakan berubah, rekaman ini harus diperbarui (ini memberi sinyal kepada pengirim untuk meminta ulang kebijakan). Misalnya,_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Pengirim



Pengirim meminta data DNS _mta-sts, jika tersedia, membuat permintaan kebijakan melalui HTTPS (memverifikasi sertifikat). Kebijakan yang dihasilkan disimpan dalam cache (jika penyerang memblokir akses ke sana atau mengubah data DNS).



Saat mengirim email, diperiksa bahwa:

• server tujuan pengiriman email ada dalam kebijakan;
• server menerima email menggunakan TLS (STARTTLS) dan memiliki sertifikat yang valid.

Manfaat MTA-STS

MTA-STS menggunakan teknologi yang sudah diterapkan di sebagian besar organisasi (SMTP + STARTTLS, HTTPS, DNS). Untuk implementasi di sisi penerima, tidak diperlukan dukungan perangkat lunak khusus untuk standar tersebut.

Kekurangan MTA-STS

Anda perlu memantau validitas web dan sertifikat server surat, korespondensi nama, dan pembaruan tepat waktu. Masalah dengan sertifikat akan membuat pengiriman email menjadi tidak mungkin.



Di sisi pengirim, MTA dengan dukungan untuk kebijakan MTA-STS diperlukan, saat ini MTA-STS tidak didukung di MTA.



MTA-STS menggunakan daftar CA root tepercaya.



MTA-STS tidak melindungi dari serangan di mana penyerang menggunakan sertifikat yang valid. Dalam kebanyakan kasus, MitM dekat server menyiratkan kemungkinan untuk menerbitkan sertifikat. Serangan semacam itu dapat dideteksi melalui Transparansi Sertifikat. Oleh karena itu, secara umum, MTA-STS mengurangi, tetapi tidak sepenuhnya menghilangkan kemungkinan intersepsi lalu lintas.



Dua poin terakhir membuat MTA-STS kurang aman dibandingkan standar DANE yang bersaing untuk SMTP (RFC 7672), tetapi lebih aman secara teknis, mis. untuk MTA-STS, kecil kemungkinannya surat tidak akan dikirimkan karena kendala teknis yang disebabkan oleh penerapan standar.

Standar bersaing - DANE

DANE menggunakan DNSSEC untuk mempublikasikan informasi sertifikat dan tidak memerlukan kepercayaan pada CA eksternal, yang jauh lebih aman. Tetapi penggunaan DNSSEC secara signifikan lebih mungkin menyebabkan kegagalan teknis, jika kita mengandalkan statistik selama beberapa tahun penggunaan (meskipun ada tren positif dalam keandalan DNSSEC dan dukungan teknisnya secara umum). Untuk mengimplementasikan DANE di SMTP di sisi penerima, keberadaan DNSSEC untuk zona DNS adalah wajib, dan untuk DANE sangat penting untuk memiliki dukungan yang benar untuk NSEC / NSEC3, dimana DNSSEC memiliki masalah sistemik.



Jika DNSSEC dikonfigurasi dengan kesalahan, ini dapat menyebabkan penolakan pengiriman email jika sisi pengirim mendukung DANE, bahkan jika sisi penerima tidak tahu apa-apa tentang itu. Oleh karena itu, terlepas dari kenyataan bahwa DANE adalah standar yang lebih tua dan lebih aman dan sudah didukung di beberapa perangkat lunak server di sisi pengirim, pada kenyataannya penetrasi tetap tidak signifikan, banyak organisasi yang tidak siap untuk mengimplementasikannya karena kebutuhan untuk mengimplementasikan DNSSEC, ini secara signifikan memperlambat implementasi DANE. bertahun-tahun standar itu ada.



DANE dan MTA-STS tidak saling bertentangan dan dapat digunakan bersama.

Ada apa dengan dukungan MTA-STS di Mail.ru Mail

Mail.ru telah menerbitkan kebijakan MTA-STS untuk semua domain utama selama beberapa waktu sekarang. Kami sedang menerapkan standar sisi klien. Pada saat penulisan ini, kebijakan diterapkan dalam mode non-pemblokiran (jika pengiriman diblokir oleh kebijakan, surat tersebut akan dikirim melalui server "cadangan" tanpa menerapkan kebijakan), kemudian mode pemblokiran akan dipaksa untuk sebagian kecil lalu lintas SMTP keluar, secara bertahap untuk 100% lalu lintas penegakan kebijakan didukung.

Siapa lagi yang mendukung standar

Sejauh ini, kebijakan MTA-STS memublikasikan sekitar 0,05% domain aktif, namun, kebijakan tersebut sudah melindungi lalu lintas email dalam jumlah besar, karena standar ini didukung oleh pemain utama - Google, Comcast dan sebagian Verizon (AOL, Yahoo). Banyak layanan pos lainnya telah mengumumkan bahwa dukungan untuk standar tersebut akan diterapkan dalam waktu dekat.

Bagaimana ini akan mempengaruhi saya?

Tidak ada jika domain Anda tidak mempublikasikan kebijakan MTA-STS. Jika Anda memublikasikan kebijakan, pesan ke pengguna server email Anda akan lebih terlindungi dari intersepsi.

Bagaimana cara menerapkan MTA-STS?

Dukungan MTA-STS di sisi penerima



Cukup mempublikasikan kebijakan melalui HTTPS dan data DNS, mengonfigurasi sertifikat yang valid dari salah satu CA tepercaya (Mari mengenkripsi) untuk STARTTLS di MTA (STARTTLS didukung di semua MTA modern), dukungan khusus dari MTA tidak diperlukan ...



Langkah demi langkah akan terlihat seperti ini:

1. Konfigurasikan STARTTLS di MTA yang Anda gunakan (postfix, exim, sendmail, Microsoft Exchange, dll.).
2. , ( CA, , MX-, ).
3. TLS-RPT , ( TLS). ( example.com):
   
   
   
   

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»

   
   
   TLS SMTP tlsrpt@exmple.com.
   
   
   
   , .
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
   

   
   
   version ( STSv1), Mode , testing — ( ), enforce — «» . mode: testing, , mode: enforce.
   
   
   
   mx , ( , mx). Max_age ( DNS- , mta-sts DNS).
5. Publikasikan data TXT ke DNS: 
   
   
   
   

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

   
   
   Di bidang id, Anda dapat menggunakan pengenal arbitrer (misalnya, stempel waktu), saat mengubah kebijakan, itu harus berubah, ini memungkinkan pengirim untuk memahami bahwa mereka perlu meminta ulang kebijakan yang di-cache (jika pengenal berbeda dari yang di-cache).

Dukungan untuk MTA-STS di pengirim



Sementara itu buruk, karena standarnya baru.

• Exim - tidak ada dukungan bawaan, ada skrip pihak ketiga https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - tidak ada dukungan bawaan, ada skrip pihak ketiga yang dijelaskan secara rinci di Habré https://habr.com/en/post/424961/

Sebagai penutup pada "TLS wajib"

Regulator telah berfokus pada keamanan surat belakangan ini (dan itu hal yang baik). Misalnya, DMARC wajib untuk semua lembaga pemerintah di Amerika Serikat dan semakin dibutuhkan di sektor keuangan; di wilayah yang diatur, penetrasi standar mencapai 90%. Sekarang, beberapa regulator mewajibkan penerapan "TLS wajib" dengan domain terpisah, tetapi pada saat yang sama, mekanisme untuk memastikan "TLS wajib" tidak ditentukan, dan dalam praktiknya, pengaturan ini sering diterapkan dengan cara yang bahkan tidak secara minimal melindungi terhadap serangan nyata yang telah disediakan dalam mekanisme seperti DANE atau MTA-STS.



Jika regulator mewajibkan penerapan "wajib TLS" dengan domain terpisah, sebaiknya pertimbangkan MTA-STS atau sebagian yang setara sebagai mekanisme yang paling sesuai, ini menghilangkan kebutuhan untuk membuat pengaturan aman untuk setiap domain secara terpisah. Jika Anda mengalami kesulitan dengan penerapan sisi klien MTA-STS (hingga protokol menerima dukungan luas, kemungkinan besar akan terjadi), Anda dapat merekomendasikan pendekatan ini:

1. Publikasikan kebijakan MTA-STS dan / atau catatan DANE (masuk akal untuk menambahkan DANE hanya jika DNSSEC sudah diaktifkan untuk domain Anda, dan MTA-STS dalam hal apa pun), ini akan melindungi lalu lintas ke arah Anda dan menghilangkan kebutuhan untuk meminta layanan email lain untuk mengonfigurasi TLS wajib untuk domain Anda jika layanan pos sudah mendukung MTA-STS dan / atau DANE.
2. «» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.