Mengapa transfer email antar server email sering tidak dienkripsi?

Pengguna sering dapat memilih jika mereka ingin mengakses penyedia email mereka (seperti Gmail) menggunakan saluran aman (misalnya menggunakan HTTPS).

Namun, sepengetahuan saya, ketika menyangkut komunikasi mail-server-ke-mail-server, sebagian besar email masih ditransfer dalam teks biasa dan tidak dienkripsi, memungkinkan siapa pun di jaringan untuk membaca konten mereka.

Apakah ada teknologi yang memberikan pengguna jaminan bahwa emailnya dikirim dengan aman dari ujung ke ujung? Mengapa tidak memberi tahu pengguna saat enkripsi tidak didukung dan biarkan dia memilih jika dia ingin emailnya tetap terkirim?

Namun, sepengetahuan saya, ketika menyangkut komunikasi mail-server-ke-mail-server, sebagian besar email masih ditransfer dalam teks biasa dan tidak dienkripsi, memungkinkan siapa pun di jaringan untuk membaca konten mereka.

Benar. SMTP, seperti HTTP, adalah teks biasa secara default.

Saat ini banyak server email yang mendukung TLS (sebelumnya dikenal sebagai SSL) untuk SMTP. (Ini termasuk Gmail.) Namun, ia memiliki masalah yang sama dengan HTTP [S]: sertifikat yang dikeluarkan oleh CA terkenal membutuhkan biaya, dan yang ditandatangani sendiri tidak bernilai ¹ untuk melindungi dari serangan MitM . Jika server email Anda melakukan validasi ketat terhadap sertifikat penerima (seperti yang dilakukan peramban web), server mungkin gagal mengirimkan pesan ke server yang menggunakan sertifikat yang ditandatangani sendiri atau CA internal. Jika tidak , maka tidak dapat memastikan bahwa itu berbicara ke server yang tepat dan bukan penipu .

Juga, TLS adalah tambahan yang relatif baru untuk SMTP, sehingga bahkan ketika server email penerima mendukung TLS, pengirim mungkin tidak, atau mungkin dinonaktifkan secara default.

¹ (Kecuali server pengirim mendukung DANE (TLSA) dan admin server penerima peduli untuk mempublikasikan catatan TLSA dalam DNS. Ini jarang dilakukan dan agak membosankan.)

Apakah ada teknologi yang memberikan pengguna jaminan bahwa emailnya dikirim dengan aman dari ujung ke ujung?

Dua standar keamanan email yang paling umum:

• OpenPGP , berdasarkan web kepercayaan dan gratis untuk digunakan. Implementasi open-source adalah GnuPG ( untuk Windows , untuk Thunderbird ), dan PGP asli telah berevolusi menjadi Desktop PGP komersial .

  Untuk klien email berbasis web, FireGPG adalah suatu kemungkinan - sial

• S / MIME , berdasarkan infrastruktur X.509. Diterapkan oleh sebagian besar klien desktop (termasuk Outlook, Thunderbird, Mail.app). Namun, relatif tidak populer karena struktur berbasis otoritas yang sama dengan TLS / SSL: sertifikat yang ditandatangani membutuhkan biaya, dan yang ditandatangani sendiri tidak dapat divalidasi dengan andal.

Dalam kedua kasus, enkripsi mensyaratkan bahwa penerima harus sudah menggunakan sistem dan telah menghasilkan / memperoleh keypair. (Untuk penandatanganan , keypair pengirim digunakan. Praktik normal adalah untuk menandatangani dan mengenkripsi pesan.)

Mengapa tidak memberi tahu pengguna saat enkripsi tidak didukung dan biarkan dia memilih jika dia ingin emailnya tetap terkirim?

Biasanya pesan yang dikirim diantrikan , dan baik pengguna maupun MTA tidak dapat mengetahui apakah hop berikutnya mendukung TLS atau tidak - sampai pesan dikirim , pada titik mana tidak ada cara yang dapat diandalkan untuk meminta konfirmasi kepada pengguna. (Mereka mungkin AFK, offline, tertidur, atau skrip / program. Jika saya mengirim pesan, saya ingin itu disampaikan sesegera mungkin.)

Selain itu, dengan SMTP Anda tidak pernah tahu apakah hop berikutnya adalah final atau apakah hanya akan mengirim email ke tempat lain. Tidak jarang MX cadangan berada di jaringan yang sama sekali berbeda.

Karena itu. keamanan end-to-end hanya dimungkinkan ketika kedua belah pihak menggunakan OpenPGP atau S / MIME.

Lalu lintas email aktual sering dienkripsi (TLS) tetapi ada beberapa masalah lain:

• Beberapa klien webmail yang menunjukkan pesan HTML mungkin tidak aman walaupun mereka menggunakan HTTPS, misalnya, tidak ada pemisahan keras antara kode dan data dalam HTML misalnya (elemen visual dan javascript -> serangan injeksi)

  • webmail juga menyimpan email di server alih-alih mengunduh dan menyimpannya ke komputer lokal

• Anda tidak memiliki cara untuk mengetahui apakah TLS / SSL telah digunakan di antara setiap langkah, server yang sangat kecil TIDAK MEMILIKI sertifikat yang tepat

  • pengirim setidaknya harus dapat menentukan apakah akan menerima atau gagal mengirim email menggunakan saluran yang tidak aman

• Email terletak pada server yang tidak dienkripsi atau dienkripsi oleh server

  • Anda harus percaya SETIAP server antara Anda dan penerima

• Email mungkin ditransfer menggunakan rute apa pun, Anda tidak bisa menentukan server mana yang Anda percayai (rentang alamat ip, ASes, negara, domain ..)

• Server email besar tidak menggunakan banyak sertifikat berbeda dan tidak cukup sering mengubahnya (?)

  • mungkin layak / mungkin untuk memaksa mereka (seperti USA / UK dll telah mencoba?)

• dengan mengikuti lalu lintas, mereka tahu kapan email telah dikirim dan sesuatu tentang penerima (server mana yang berkomunikasi satu sama lain)

  • darknets menyembunyikan korelasi ini

• Implementasi openssl adalah berantakan

  • mungkin ada bug

• Anda harus percaya pada otoritas sertifikat yang menandatangani sertifikat

Mereka. Atau sangat sering.

Baik melalui SSL, atau TLS .

--- 220 mail.ovalpowered.com ESMTP Exim 4.72 Sun, 20 Mar 2011 17:09:56 +0000
+++ EHLO test
--- 250-mail.ovalpowered.com Hello vpnhub.sqsol.co.uk [213.229.101.173]
--- 250-SIZE 52428800
--- -PIPELINING
--- -AUTH PLAIN LOGIN
--- -STARTTLS
--- HELP
+++ STARTTLS
--- 220 TLS go ahead

Atau jika Anda benar-benar paranoid ada PGP atau GPG.