Singkatnya, MTA-STS adalah cara untuk lebih melindungi email dari intersepsi (yaitu serangan man-in-the-middle alias MitM) saat dikirim antar server email. Ini sebagian memecahkan masalah arsitektur lama dari protokol email dan dijelaskan dalam standar RFC 8461 yang relatif baru. Mail.ru adalah layanan email besar pertama di Runet yang menerapkan standar ini. Dan itu dijelaskan lebih detail di bawah potongan.

Masalah apa yang dipecahkan oleh MTA-STS?

Secara historis, protokol email (SMTP, POP3, IMAP) mengirimkan informasi dalam bentuk teks yang jelas, yang memungkinkan untuk mencegatnya, misalnya, saat mengakses saluran komunikasi.

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

Secara historis, serangan MitM mungkin terjadi di semua tempat di mana surat beredar.

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

Mengikuti praktik yang diterima secara umum (distandarisasi oleh RFC 8314) menghilangkan serangan di dekat pengguna:

Server email Mail.ru mematuhi RFC 8314 bahkan sebelum standar ini diadopsi; sebenarnya, ini hanya menangkap praktik yang sudah diterima, dan kami tidak perlu mengonfigurasi apa pun tambahan. Namun, jika server email Anda masih mengizinkan pengguna menggunakan 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 bagi pengguna yang tidak aman untuk terhubung (inilah yang dibutuhkan oleh RFC 8314). Hal ini terkadang sulit, namun bisa dilakukan. Lalu lintas antar server email masih lebih rumit. Server milik organisasi yang berbeda dan sering kali digunakan dalam mode “setel dan lupakan”, sehingga 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. Namun penyerang yang memiliki kemampuan untuk mempengaruhi lalu lintas dapat “memotong” informasi tentang dukungan untuk perintah ini dan memaksa server untuk berkomunikasi menggunakan protokol teks biasa (yang disebut serangan downgrade). Untuk alasan yang sama, STARTTLS biasanya tidak memeriksa validitas sertifikat (sertifikat yang tidak tepercaya dapat melindungi dari serangan pasif, dan ini tidak lebih buruk daripada mengirim pesan dalam teks biasa). Oleh karena itu, STARTTLS hanya melindungi terhadap penyadapan pasif.

MTA-STS sebagian menghilangkan masalah intersepsi surat antar server email, ketika penyerang memiliki kemampuan untuk secara aktif mempengaruhi 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 verifikasi sertifikat server.

Mengapa sebagian? MTA-STS hanya berfungsi jika kedua belah pihak telah berupaya menerapkan standar ini, dan MTA-STS tidak melindungi terhadap skenario di mana penyerang dapat memperoleh sertifikat domain yang valid dari salah satu CA publik.

Cara kerja MTA-STS

penerima

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

Pengirim

Pengirim meminta catatan DNS _mta-sts, dan jika tersedia, membuat permintaan kebijakan melalui HTTPS (memeriksa sertifikat). Kebijakan yang dihasilkan disimpan dalam cache (jika penyerang memblokir akses ke kebijakan tersebut atau memalsukan data DNS).

Saat mengirim surat, diperiksa bahwa:

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

Keuntungan dari 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

Penting untuk memantau validitas sertifikat web dan server surat, korespondensi nama, dan pembaruan tepat waktu. Masalah dengan sertifikat akan mengakibatkan surat tidak dapat terkirim.

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

MTA-STS menggunakan daftar root CA yang tepercaya.

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

Dua poin terakhir membuat MTA-STS kurang aman dibandingkan standar DANE pesaing untuk SMTP (RFC 7672), namun lebih dapat diandalkan secara teknis, yaitu. untuk MTA-STS kecil kemungkinan surat tersebut tidak terkirim karena kendala teknis akibat penerapan standar tersebut.

Standar yang bersaing - DANE

DANE menggunakan DNSSEC untuk mempublikasikan informasi sertifikat dan tidak memerlukan kepercayaan pada otoritas sertifikat eksternal, sehingga jauh lebih aman. Namun penggunaan DNSSEC secara signifikan lebih sering menyebabkan kegagalan teknis, berdasarkan statistik selama beberapa tahun penggunaan (walaupun secara umum terdapat tren positif dalam keandalan DNSSEC dan dukungan teknisnya). Untuk mengimplementasikan DANE di SMTP di sisi penerima, kehadiran DNSSEC untuk zona DNS adalah wajib, dan dukungan yang benar untuk NSEC/NSEC3 sangat penting untuk DANE, yang mana terdapat masalah sistemik di DNSSEC.

Jika DNSSEC tidak dikonfigurasi dengan benar, hal ini dapat mengakibatkan kegagalan pengiriman email jika pihak pengirim mendukung DANE, meskipun pihak penerima tidak mengetahui apa pun tentangnya. Oleh karena itu, meskipun DANE adalah standar yang lebih lama dan lebih aman serta sudah didukung di beberapa perangkat lunak server di sisi pengirim, kenyataannya penetrasinya masih kecil, banyak organisasi belum siap untuk menerapkannya karena kebutuhan untuk mengimplementasikan DNSSEC, hal ini telah memperlambat penerapan DANE secara signifikan selama bertahun-tahun standar tersebut ada.

DANE dan MTA-STS tidak bertentangan satu sama lain 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. Kami sedang menerapkan standar bagian klien. Pada saat penulisan, kebijakan diterapkan dalam mode non-pemblokiran (jika pengiriman diblokir oleh suatu kebijakan, surat akan dikirimkan melalui server “cadangan” tanpa menerapkan kebijakan), maka mode pemblokiran akan dipaksakan untuk sebagian kecil. lalu lintas SMTP keluar, secara bertahap untuk 100% lalu lintas akan didukung. Penegakan kebijakan didukung.

Siapa lagi yang mendukung standar ini?

Sejauh ini, kebijakan MTA-STS mempublikasikan sekitar 0.05% domain aktif, namun tetap melindungi sejumlah besar lalu lintas email, karena Standar ini didukung oleh pemain besar - Google, Comcast dan sebagian Verizon (AOL, Yahoo). Banyak layanan pos lain yang mengumumkan bahwa dukungan terhadap standar ini akan diterapkan dalam waktu dekat.

Bagaimana pengaruhnya terhadap saya?

Tidak, kecuali domain Anda menerbitkan kebijakan MTA-STS. Jika Anda memublikasikan kebijakan tersebut, email untuk pengguna server email Anda akan lebih terlindungi dari intersepsi.

Bagaimana cara menerapkan MTA-STS?

Dukungan MTA-STS di sisi penerima

Cukup dengan mempublikasikan kebijakan melalui HTTPS dan mencatat dalam DNS, mengkonfigurasi sertifikat yang valid dari salah satu CA tepercaya (Mari kita mengenkripsi dimungkinkan) untuk STARTTLS di MTA (STARTTLS didukung di semua MTA modern), tidak ada dukungan khusus dari MTA diperlukan.

Langkah demi langkah tampilannya seperti ini:

Konfigurasikan STARTTLS di MTA yang Anda gunakan (postfix, exim, sendmail, Microsoft Exchange, dll).
Pastikan Anda menggunakan sertifikat yang valid (dikeluarkan oleh CA tepercaya, tidak kedaluwarsa, subjek sertifikat cocok dengan data MX yang mengirimkan email untuk domain Anda).
Konfigurasikan data TLS-RPT yang akan digunakan untuk mengirimkan laporan aplikasi kebijakan (oleh layanan yang mendukung pengiriman laporan TLS). Contoh entri (untuk domain example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Entri ini menginstruksikan pengirim email untuk mengirimkan laporan statistik tentang penggunaan TLS di SMTP ke [email protected].

Pantau laporan selama beberapa hari untuk memastikan tidak ada kesalahan.
Publikasikan kebijakan MTA-STS melalui HTTPS. Kebijakan ini dipublikasikan sebagai file teks dengan terminator garis CRLF berdasarkan lokasi.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Contoh kebijakan:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Bidang versi berisi versi kebijakan (saat ini STSv1), Mode menetapkan mode penerapan kebijakan, pengujian — mode pengujian (kebijakan tidak diterapkan), penegakan — mode “pertempuran”. Publikasikan dulu kebijakan dengan mode: pengujian, jika tidak ada masalah dengan kebijakan dalam mode pengujian, setelah beberapa saat Anda dapat beralih ke mode: penegakan.

Di mx, daftar semua server email yang dapat menerima email untuk domain Anda ditentukan (setiap server harus memiliki sertifikat yang dikonfigurasi yang cocok dengan nama yang ditentukan di mx). Max_age menentukan waktu caching kebijakan (setelah kebijakan yang diingat akan diterapkan bahkan jika penyerang memblokir pengirimannya atau merusak catatan DNS selama waktu caching, Anda dapat memberi sinyal perlunya meminta kebijakan lagi dengan mengubah DNS mta-sts catatan).
Publikasikan data TXT di DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Pengidentifikasi arbitrer (misalnya, stempel waktu) dapat digunakan di bidang id; ketika kebijakan berubah, kebijakan tersebut harus berubah, hal ini memungkinkan pengirim memahami bahwa mereka perlu meminta ulang kebijakan yang di-cache (jika pengidentifikasi berbeda dari di-cache satu).

Dukungan MTA-STS di sisi pengirim

Sejauh ini keadaannya buruk, karena... standar segar.

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 kata penutup tentang “TLS wajib”

Akhir-akhir ini, regulator menaruh perhatian pada keamanan email (dan itu merupakan hal yang baik). Misalnya, DMARC bersifat wajib bagi semua lembaga pemerintah di Amerika Serikat dan semakin diwajibkan di sektor keuangan, dengan penetrasi standar mencapai 90% di bidang yang diatur. Saat ini beberapa regulator mengharuskan penerapan “TLS wajib” dengan domain individual, namun mekanisme untuk memastikan “TLS wajib” tidak ditentukan dan dalam praktiknya pengaturan ini sering diterapkan dengan cara yang bahkan tidak memberikan perlindungan minimal terhadap serangan nyata yang sudah terjadi. disediakan dalam mekanisme seperti DANE atau MTA-STS.

Jika regulator mengharuskan penerapan “TLS wajib” dengan domain terpisah, kami merekomendasikan untuk mempertimbangkan MTA-STS atau analog parsialnya sebagai mekanisme yang paling sesuai, sehingga menghilangkan kebutuhan untuk membuat pengaturan aman untuk setiap domain secara terpisah. Jika Anda mengalami kesulitan dalam mengimplementasikan bagian klien MTA-STS (sebelum protokol tersebut menerima dukungan luas, kemungkinan besar mereka akan mengalami kesulitan), kami dapat merekomendasikan pendekatan ini:

Publikasikan kebijakan MTA-STS dan/atau data DANE (DANE hanya masuk akal 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 menanyakan layanan email lainnya untuk mengonfigurasi TLS wajib untuk domain Anda jika layanan email sudah mendukung MTA-STS dan/atau DANE.
Untuk layanan email besar, terapkan “analog” MTA-STS melalui pengaturan transport terpisah untuk setiap domain, yang akan memperbaiki MX yang digunakan untuk menyampaikan email dan akan memerlukan verifikasi wajib sertifikat TLS untuk itu. Jika domain sudah memublikasikan kebijakan MTA-STS, hal ini mungkin dapat dilakukan tanpa kesulitan. Dengan sendirinya, mengaktifkan TLS wajib untuk domain tanpa memperbaiki relai dan memverifikasi sertifikatnya tidak efektif dari sudut pandang keamanan dan tidak menambahkan apa pun ke mekanisme STARTTLS yang ada.

Sumber: www.habr.com

Mail.ru mail mulai menerapkan kebijakan MTA-STS dalam mode uji