Sebagai teknologi komunikasi digital, Email terus mendominasi dan berkembang penggunaannya. Dalam posting saya sebelumnya , saya menyoroti banyak keutamaannya tetapi juga menyinggung beberapa kelemahan yang sama sekali tidak disadari oleh sebagian besar pengguna.

Dalam posting ini kita akan mengeksplorasi kelemahan ini secara lebih rinci dan khususnya dengan bagaimana email ditransmisikan antar server. Kami juga akan menyoroti bagaimana kelemahan ini dapat diatasi dengan peningkatan pengadopsian ekstensi yang sudah ada ke protokol email tradisional (mis. DANE).

Seperti biasa, artikel ini didasarkan pada penelitian dan praktik pribadi saya dalam subjek tersebut, tetapi berbagi pengetahuan adalah sebuah kolaborasi, jadi mohon berikan komentar atau umpan balik.

pengantar

Untuk memudahkan pemahaman, saya akan menyoroti tiga fase tingkat tinggi tentang bagaimana koneksi antara server surat dibuat.

Penemuan server email penerima , proses menemukan server email mana yang dimaksudkan untuk menerima email untuk domain penerima tertentu.

Sambungan ke server surat penerima, setelah mengidentifikasi server surat yang benar, proses menyambungkannya dan mengamankan sambungan dengan enkripsi yang sesuai (alias TLS).

Memverifikasi bahwa server email penerima memang benar, dapatkah kami memastikan bahwa kami telah membuat sambungan aman ke server yang sah untuk domain penerima.

Penemuan server email penerima

Hal ini paling sering dicapai melalui pencarian DNS dari data MX (Mail Exchange) yang mengarah ke satu atau beberapa alamat IP server email yang dimaksudkan untuk menerima email untuk domain penerima. Namun ada mekanisme lain seperti MTA-STS, catatan SRV atau bahkan catatan A. Kami akan membahas beberapa elemen MTA-STS lebih lanjut di bawah tetapi bukan pendekatan rekor SRV/A (walaupun mereka memiliki kelemahan yang sama).

Penemuan server email bergantung pada DNS , dan sebagian besar kueri DNS masih mengandalkan paket UDP dan karenanya tidak terhubung dan tidak terenkripsi, membuatnya relatif mudah untuk mencegat dan menyuntikkan tanggapan palsu.

Meskipun ada implementasi DNS yang menggunakan TCP, TLS, dan bahkan DNS melalui HTTPS , implementasi tersebut agak jarang tetapi mengurangi potensi intersepsi dan injeksi antara klien dan server.

Namun penerapan TCP/TLS berfokus pada peningkatan atau pengamanan koneksi, mereka sendiri tidak menyediakan mekanisme untuk memastikan bahwa data, respons terhadap pencarian DNS, adalah asli dan belum dirusak.

Di sinilah DNSSEC masuk, ini memberikan pendekatan penandatanganan digital berlabuh kepercayaan yang memastikan setiap respons DNS untuk domain yang diaktifkan DNSSEC dapat divalidasi secara kriptografis sebagai asli dan otoritatif.

Bagaimana dengan DANA?

• DANE memerlukan DNSSEC untuk semua pencarian DNS, yang berhasil mengurangi risiko ini.

• MTA-STS menerbitkan server email, otoritatif untuk domain, dengan mencantumkannya dalam file kebijakan MTA-STS yang dihosting di server web. Sementara koneksi ke server web itu sendiri mungkin HTTPS (dengan validasi sertifikat), itu tidak mengharuskan pencarian DNS dari server web itu aman.
• MTA-STS tidak mengamanatkan penggunaan DNSSEC, sebenarnya pemahaman saya adalah salah satu 'fitur desainnya' adalah tidak bergantung pada DNSSEC.

• Penemuan server surat domain penerima tergantung pada DNS yang tanpa DNSSEC tidak memiliki keamanan untuk memberikan jaminan atas respons yang diterima.
• DANE mengamanatkan penggunaan DNSSEC, sehingga sebagai perluasan ke SMTP, ini adalah mekanisme yang paling efektif untuk memberikan perlindungan terhadap risiko ini.
• MTA-STS tidak mengamanatkan penggunaan DNSSEC dan meskipun menghosting kebijakan di server aman HTTPS, masih bergantung pada pencarian DNS tradisional.
• Namun MTA-STS dapat digunakan dengan DNSSEC yang akan mengurangi sebagian besar risiko ini. Ini akan menjadi rekomendasi saya jika Anda sedang dalam proses menerapkan MTA-STS.

Dunia beralih ke HTTPS dalam sekejap mata. Sangat tidak biasa hari ini untuk menemukan situs web apa pun yang tidak mendukung HTTPS (bahkan yang tidak mengambil detail kartu kredit Anda). Namun email belum melihat perubahan langkah yang sama dalam keamanan dan masih bergantung pada apa yang kami sebut "TLS oportunistik". Dalam TLS Oportunistik, server pertama-tama akan membuat koneksi yang tidak aman dan kemudian mencoba untuk bernegosiasi dan memutakhirkan koneksi ke TLS tetapi dengan senang hati akan melanjutkan tanpa TLS jika, karena alasan apa pun, mereka tidak setuju.

Masalah sebenarnya di sini adalah bahwa "TLS oportunistik" awalnya membuka koneksi tidak aman dan memutakhirkannya ke TLS (diprakarsai oleh metode STARTTLS). Oleh karena itu relatif mudah untuk mencegat koneksi semacam itu dan menghambat pemutakhiran ke TLS dengan menyembunyikan dukungan STARTTLS dari server jarak jauh. Server email TLS oportunistik kemudian akan melanjutkan pertukaran email tanpa peduli atau pertimbangan. Lebih buruk lagi, baik pengirim maupun penerima tidak menyadari bahwa hal ini telah terjadi.

Kedua pihak dalam koneksi TLS menggunakan sertifikat PKI yang juga dapat digunakan untuk memberikan tingkat kepercayaan tambahan bahwa para pihak memang seperti yang mereka katakan dan dapat diverifikasi secara independen melalui jangkar kepercayaan . Namun mengingat betapa mudahnya mendapatkan sertifikat dari penyedia seperti LetsEncrypt, ini menjadi kurang dapat diandalkan.

Dalam praktiknya, sebagian besar server email mendukung beberapa bentuk TLS sehingga kemungkinan besar email Anda dienkripsi saat melintasi Internet ke tujuannya. Namun itu tidak mengatasi risiko serangan MITM yang menutupi dukungan TLS dan mengizinkan koneksi yang tidak terenkripsi.

Bagaimana dengan MTA-STS?

• MTA-STS mengatasi risiko ini dengan (dan dengan asumsi Anda tidak dalam mode 'pengujian') secara implisit mengharuskan koneksi TLS harus dibuat untuk pertukaran email.

• DANE memberlakukan persyaratan implisit untuk koneksi TLS dan juga mengurangi risiko ini.

• TLS oportunistik bergantung pada koneksi yang tidak terenkripsi untuk menetapkan kemungkinan pemutakhiran ke TLS dan karenanya rentan terhadap serangan MITM.
• Baik DANE dan MTA-STS secara implisit memerlukan koneksi TLS sebelum email akan dipertukarkan sehingga efektif dalam memastikan setidaknya koneksi TLS dasar dibuat.
• TLS saja tidak cukup untuk menunjukkan bahwa koneksi cukup aman/dienkripsi. Banyak protokol dan cipher suite yang diimplementasikan dalam TLS dianggap tidak aman (brute forcable). Ini adalah keseluruhan topik itu sendiri yang akan kita bahas di artikel selanjutnya.

Ini bisa dibilang merupakan langkah dalam proses membangun koneksi aman antara server email. Namun menurut saya, ini adalah elemen yang sangat penting sehingga layak untuk bagiannya sendiri.

Menyadari ketergantungan pada fase sebelumnya, menjadi penting bahwa kami dapat memvalidasi lebih lanjut bahwa server yang kami sambungkan, memang server yang berwenang untuk domain penerima. Fase sebelumnya menjelaskan pembuatan koneksi TLS yang mungkin menyertakan atau tidak menyertakan Verifikasi Sertifikat. Namun secara umum, semua Verifikasi Sertifikat biasanya dilakukan untuk memvalidasi bahwa nama host yang diberikan cocok dengan nama host yang dirinci dalam sertifikat di server jarak jauh dan secara opsional jika dapat diikat kembali ke jangkar kepercayaan.

DANE mengambil satu langkah lebih jauh dengan menerbitkan catatan TLSA aman DNSSEC yang menyimpan sidik jari (dan metode validasi) untuk sertifikat server surat yang diberikan. Ini memberikan validasi andal dan terakhir yang secara pasti memastikan bahwa server yang Anda sambungkan menyajikan sertifikat khusus yang dikenali oleh administrator DNS.

Bagaimana dengan DANA?

• Validasi sertifikat server terhadap catatan TLSA aman DNSSEC, melekat pada DANE dan memberikan segel persetujuan akhir untuk memastikan koneksi.

• MTA-STS tidak sejauh ini, tujuannya difokuskan untuk memastikan koneksi TLS wajib dan tidak meluas untuk memvalidasi otoritas server email.

Dalam pikiran saya tidak ada alasan rasional bahwa kelemahan ini harus tetap tidak dikurangi di sebagian besar penyedia email. Teknologi ada untuk mengatasinya dan relatif mudah digunakan akhir-akhir ini. Asumsi saya adalah kurangnya kesadaran dari konsumen menghilangkan banyak insentif bagi penyedia surat untuk menerapkan teknologi ini.

MTA-STS memberikan beberapa peningkatan utama pada masalah TLS Oportunistik tetapi tidak cukup jauh untuk mengatasi semua kelemahannya. Menambahkan DNSSEC ke MTA-STS memang mengurangi beberapa risiko dan akan menjadi rekomendasi saya (jika DANE bukan pilihan untuk Anda).

Namun DANE memberikan solusi komprehensif untuk kelemahan yang dibahas dalam artikel ini. Jika Anda mempertimbangkan MTA-STS dan DANE tetapi hanya ingin memilih satu, maka DANE akan menjadi rekomendasi saya.

Ada sekitar 365 juta nama domain yang terdaftar di seluruh dunia, dan hanya 3,7 juta domain yang telah menggunakan DANE (sekitar 1%).

Jika kami melihat penyedia email terbesar, kami mencatat bahwa Gmail telah menerapkan MTA-STS tetapi belum menerapkan DANE atau bahkan DNSSEC.

Demikian pula Microsoft telah menerapkan MTA-STS ke Exchange Online tahun ini dan telah mengumumkan niat mereka untuk menawarkan DANE di masa mendatang, tetapi kemungkinan akan memakan waktu beberapa tahun lagi sebelum mereka mendukungnya baik keluar maupun masuk.