Apakah STARTTLS kurang aman daripada TLS / SSL?

Di Thunderbird (dan saya berasumsi di banyak klien lain, juga) saya memiliki opsi untuk memilih antara "SSL / TLS" dan "STARTTLS".

Sejauh yang saya mengerti, "STARTTLS" berarti dalam kata-kata sederhana "mengenkripsi jika kedua ujungnya mendukung TLS, jika tidak jangan mengenkripsi transfer" . Dan "SSL / TLS" berarti dalam kata-kata sederhana "selalu mengenkripsi atau tidak terhubung sama sekali" . Apakah ini benar?

Atau dengan kata lain:

Apakah STARTTLS kurang aman daripada SSL / TLS, karena STARTTLS dapat mundur ke plaintext tanpa memberi tahu saya?

Jawabannya, berdasarkan STARTTLS RFC untuk SMTP ( RFC 3207 ) adalah:

STARTTLS kurang aman dibandingkan TLS.

Alih-alih berbicara sendiri, saya akan membiarkan RFC berbicara sendiri, dengan empat bit yang relevan disorot dalam BOLD :

Serangan man-in-the-middle dapat diluncurkan dengan menghapus respons "250 STARTTLS" dari server. Ini akan menyebabkan klien tidak mencoba memulai sesi TLS. Serangan man-in-the-middle lainnya adalah untuk memungkinkan server mengumumkan kapabilitas STARTTLS-nya, tetapi untuk mengubah permintaan klien untuk memulai TLS dan respons server. Untuk mempertahankan diri dari serangan semacam itu, baik klien dan server HARUS dapat dikonfigurasi untuk mensyaratkan keberhasilan negosiasi TLS dari rangkaian sandi yang sesuai untuk host terpilih sebelum pesan dapat berhasil ditransfer. Opsi tambahan untuk menggunakan TLS bila memungkinkan HARUS juga disediakan. Suatu implementasi MUNGKIN memberikan kemampuan untuk merekam bahwa TLS digunakan dalam berkomunikasi dengan rekan yang diberikan dan menghasilkan peringatan jika tidak digunakan dalam sesi selanjutnya.

Jika negosiasi TLS gagal atau jika klien menerima respons 454, klien harus memutuskan apa yang harus dilakukan selanjutnya. Ada tiga pilihan utama: lanjutkan dengan sisa sesi SMTP , [...]

Seperti yang Anda lihat, RFC sendiri menyatakan (tidak terlalu jelas, tapi cukup jelas) bahwa TIDAK ADA yang mengharuskan klien untuk membuat koneksi aman dan memberi tahu pengguna jika koneksi aman gagal. Ini secara eksplisit memberi klien opsi untuk diam-diam membangun koneksi teks biasa .

Tidak ada perbedaan dalam keamanan antara dua opsi.

• SSL / TLS membuka koneksi SSL / TLS terlebih dahulu, kemudian memulai transaksi SMTP. Ini harus terjadi pada port yang tidak memiliki server SMTP non-SSL / TLS sudah berjalan; tidak mungkin untuk mengkonfigurasi satu port untuk menangani teks biasa dan koneksi terenkripsi karena sifat protokol.

• STARTTLS memulai transaksi SMTP dan mencari dukungan dari ujung lain untuk TLS dalam menanggapi EHLO. Jika klien melihat STARTTLS dalam daftar perintah yang didukung, maka ia mengirim STARTTLS dan memulai negosiasi untuk enkripsi. Semua ini dapat (dan biasanya memang) terjadi pada port SMTP standar 25, sebagian untuk kompatibilitas mundur, tetapi juga untuk memungkinkan enkripsi oportunistik antara titik akhir yang keduanya mendukung tetapi tidak selalu memerlukannya.

Secara umum, SSL / TLS hanya digunakan antara klien akhir dan server. STARTTLS lebih umum digunakan antara MTA untuk mengamankan transportasi antar-server.

Dengan kedua implementasi tersebut, STARTTLS dapat ditafsirkan sebagai tidak aman jika pengguna atau administrator menganggap koneksi dienkripsi tetapi belum benar-benar mengkonfigurasinya untuk memerlukan enkripsi. Namun, enkripsi yang digunakan persis sama dengan SSL / TLS dan karenanya tidak lebih atau kurang rentan terhadap serangan Man-in-the-Middle di luar jenis kesalahan konfigurasi ini.

Untuk email khususnya, pada Januari 2018 RFC 8314 dirilis, yang secara eksplisit merekomendasikan bahwa "TLS implisit" digunakan dalam preferensi untuk mekanisme STARTTLS untuk pengiriman IMAP, POP3, dan SMTP.

Secara singkat, memo ini sekarang merekomendasikan bahwa:

• TLS versi 1.2 atau lebih tinggi digunakan untuk semua lalu lintas antara MUA dan Server Pengiriman Email, dan juga antara MUA dan Server Akses Mail.
• MUA dan Penyedia Layanan Surat (MSP) (a) tidak menyarankan penggunaan protokol cleartext untuk akses surat dan pengiriman surat dan (b) menghentikan penggunaan protokol cleartext untuk tujuan ini secepat mungkin.
• Koneksi ke Server Pengiriman Email dan Server Akses Email dibuat menggunakan "TLS implisit" (sebagaimana didefinisikan di bawah), dalam preferensi untuk menghubungkan ke port "cleartext" dan menegosiasikan TLS menggunakan perintah STARTTLS atau perintah serupa.

(penekanan ditambahkan)

Jawabannya sedikit banyak tergantung pada apa yang Anda maksud dengan "aman".

Pertama, ringkasan Anda tidak cukup menangkap perbedaan antara SSL / TLS dan STARTTLS.

• Dengan SSL / TLS, klien membuka koneksi TCP ke "port SSL" yang ditetapkan untuk protokol aplikasi yang ingin digunakan, dan mulai berbicara TLS segera.
• Dengan STARTTLS, klien membuka koneksi TCP ke "port cleartext" yang terkait dengan protokol aplikasi yang ingin digunakan, kemudian meminta server "ekstensi protokol apa yang Anda dukung?". Server kemudian merespons dengan daftar ekstensi. Jika salah satu dari ekstensi itu adalah "STARTTLS", klien kemudian dapat mengatakan "oke, mari kita gunakan TLS" dan keduanya mulai berbicara TLS.

Jika klien dikonfigurasi untuk memerlukan TLS, kedua pendekatan lebih atau kurang sama-sama aman. Tetapi ada beberapa seluk-beluk tentang bagaimana STARTTLS harus digunakan untuk membuatnya aman, dan itu agak sulit untuk implementasi STARTTLS untuk memperbaikinya.

Di sisi lain, jika klien dikonfigurasikan untuk menggunakan TLS hanya ketika TLS tersedia, dan menggunakan cleartext ketika TLS tidak tersedia, apa yang mungkin dilakukan klien pertama kali adalah mencoba menghubungkan ke port SSL yang digunakan oleh protokol, dan jika itu gagal, kemudian sambungkan ke port cleartext dan coba gunakan STARTTLS, dan akhirnya kembali ke cleartext jika TLS tidak tersedia dalam kedua kasus. Ini cukup mudah bagi penyerang untuk menyebabkan koneksi port SSL gagal (yang diperlukan hanyalah beberapa paket TCP RST yang tepat waktu atau pemblokiran port SSL). Ini sedikit lebih sulit - tetapi hanya sedikit - bagi seorang penyerang untuk mengalahkan negosiasi STARTTLS dan menyebabkan lalu lintas tetap dalam teks yang jelas. Dan kemudian penyerang tidak hanya dapat membaca email Anda tetapi juga mendapatkan untuk menangkap nama pengguna / kata sandi Anda untuk digunakan di masa depan.

Jadi jawaban sederhananya adalah jika Anda terhubung ke server yang sudah Anda ketahui mendukung TLS (sebagaimana seharusnya ketika Anda mengirim atau membaca email), Anda harus menggunakan SSL / TLS. Jika koneksi sedang diserang, upaya koneksi akan gagal, tetapi kata sandi dan email Anda tidak akan terganggu.

Di sisi lain, jika Anda terhubung ke beberapa layanan yang Anda tidak tahu apakah itu mendukung TLS, STARTTLS mungkin sedikit lebih baik.

Ketika STARTTLS ditemukan, serangan hanya mendengarkan "pasif" sangat umum, serangan "aktif" di mana penyerang akan menyuntikkan lalu lintas untuk mencoba menurunkan keamanan adalah kurang umum. Dalam 20 tahun atau lebih sejak itu, serangan aktif menjadi lebih layak dan lebih umum.

Misalnya, jika Anda mencoba menggunakan laptop di bandara atau tempat umum lainnya dan mencoba membaca email Anda melalui wifi yang disediakan di sana, Anda tidak tahu apa yang dilakukan jaringan wifi dengan lalu lintas Anda. Sangat umum bagi jaringan wifi untuk merutekan jenis lalu lintas tertentu ke "proxy" yang menempatkan diri mereka di antara aplikasi klien Anda dan server yang mereka coba ajak bicara. Sepele bagi proksi tersebut untuk menonaktifkan STARTTLS dan "coba satu port lalu port lain" dalam upaya untuk membuat klien Anda kembali ke menghapus teks. Ya, ini terjadi, dan itu hanyalah satu contoh bagaimana lalu lintas Anda dapat dimata-matai oleh jaringan. Dan serangan seperti itu tidak terbatas pada tiga huruf lembaga yang didukung negara,

Ya, Anda memiliki dasar-dasarnya yang benar. Dan ya, STARTTLS jelas kurang aman. Tidak hanya itu bisa kembali ke plaintext tanpa pemberitahuan, tetapi karena itu tunduk pada serangan tengah. Karena koneksi dimulai dengan jelas, MitM dapat menghapus perintah STARTTLS, dan mencegah enkripsi agar tidak pernah terjadi. Namun, saya yakin mailservers dapat menentukan bahwa transfer hanya terjadi setelah terowongan terenkripsi telah disiapkan. Jadi Anda bisa mengatasi ini.

Jadi mengapa hal seperti itu ada? Untuk alasan kompatibilitas. Jika kedua sisi tidak mendukung enkripsi, Anda mungkin masih ingin koneksi selesai dengan baik.

Setuju dengan @Greg. Serangan-serangan itu mungkin terjadi. Namun MTA dapat dikonfigurasi (tergantung pada MTA) untuk menggunakan "TLS wajib", bukan "TLS oportunistik". Ini artinya TLS dan hanya TLS yang digunakan (ini juga termasuk STARTTLS) untuk transaksi email. Jika MTA jarak jauh tidak mendukung STARTTLS, email terpental.

Tidak, itu tidak kalah aman, ketika aplikasi Anda menanganinya dengan benar.

Ada empat cara untuk menangani TLS dan banyak program memungkinkan Anda untuk memilih:

• Tidak ada TLS
• TLS pada port khusus (hanya mencoba TLS)
• Gunakan TLS jika tersedia (Coba starttls, gunakan koneksi yang tidak dienkripsi ketika gagal)
• Selalu gunakan TLS (Menggunakan starttlsdan gagal jika tidak berhasil)

Keuntungan TLS pada port khusus adalah, Anda dapat yakin tidak ada fallback ketika Anda menggunakan program yang belum Anda ketahui atau yang tidak memaparkan pengaturan detail untuk penanganan kesalahan dalam wisaya awal pertama.

Namun secara umum keamanan tergantung pada penanganan kesalahan keamanan. Suatu program dapat memutuskan untuk beralih ke port plaintext ketika TLS pada TLS-Port juga gagal. Anda perlu tahu apa yang akan dilakukan dan memilih pengaturan yang aman. Dan program harus menggunakan default yang aman.