Transport TLS dan S/MIME memecahkan masalah yang berbeda. TLS melindungi koneksi antar sistem yang berdekatan. S/MIME dapat menandatangani atau mengenkripsi konten pesan sehingga perlindungan menyertai pesan tersebut. Apakah itu benar-benar end-to-end tergantung pada di mana kunci disimpan dan di mana penandatanganan atau dekripsi terjadi, bukan hanya apakah klien email menampilkan ikon keamanan.
Gambarkan jalurnya sebelum memilih kontrol
Referensi: RFC 3207 §1, RFC 8551 §1.
Gunakan pesan dari klien Alice ke layanan pengirimannya, lalu gerbang keluar, layanan MX penerima, serta kotak surat dan klien Bob. Setiap hop jaringan dapat memiliki koneksi dan kebijakan TLS sendiri. Koneksi SMTP TLS antar-domain yang berhasil tidak menjelaskan apa pun tentang pengiriman, relai internal, akses kotak surat, atau enkripsi penyimpanan.
Di setiap server yang mengakhiri TLS , konten pesan biasa tersedia untuk diproses kecuali jika dienkripsi secara terpisah. Oleh karena itu, filter, gateway, dan titik akhir yang disusupi tetap menjadi bagian dari batasan kerahasiaan. MTA-STS dan SMTP DANE meningkatkan otentikasi dan penegakan transportasi untuk rute-rute yang berlaku; tidak ada yang mengubah TLS hop-by-hop menjadi enkripsi pesan. RFC 8461 bagian 2.
Bedakan penandatanganan dari enkripsi
Referensi: RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.
Konten yang ditandatangani S/MIME memberikan bukti integritas dan autentikasi penanda tangan sesuai dengan kepercayaan dan validasi sertifikat. Signing alone does not hide the message. Konten berselubung S/MIME mengenkripsi materi yang dilindungi untuk penerima yang kuncinya dapat mendekripsinya; enkripsi saja tidak setara dengan tanda tangan penulis terverifikasi. Konten teramplop yang diautentikasi juga dapat memberikan kerahasiaan dan integritas data tanpa membuktikan keasliannya, seperti yang dijelaskan RFC 8551 §3.4. Jangan samakan perlindungan itu dengan tanda tangan penulis yang terverifikasi. A workflow can combine signing and encryption. RFC 8551 bagian 2 dan 3.
Kunci dan identitas sertifikat memerlukan manajemen siklus hidup. Konfirmasikan siapa yang dapat mengakses kunci pribadi, bagaimana penerima memperoleh sertifikat, bagaimana kunci yang kedaluwarsa atau hilang memengaruhi akses ke email yang diarsipkan, dan proses pemulihan apa yang diizinkan. Itu adalah pertanyaan desain operasional, bukan alasan untuk mendistribusikan kunci privat secara luas atau menganggap pemeriksaan autentikasi domain menggantikan validasi sertifikat.
Bandingkan ancaman pada pesan yang sama
Referensi: RFC 8551 §3.1, RFC 8551 §6.
Untuk pengamatan pasif dari hop SMTP yang dienkripsi dengan benar, TLS melindungi byte yang dikirimkan pada hop tersebut. Untuk administrator gateway yang membaca email setelah penghentian TLS , enkripsi hop tidak memberikan penghalang kerahasiaan konten. Enkripsi S/MIME sisi klien dapat melindungi badan terenkripsi dari gateway tersebut jika tidak menyimpan kunci dekripsi. Kata tersebut mungkin penting karena beberapa penerapan sengaja mendekripsi di gateway.
Untuk perubahan setelah pengangkutan, tanda tangan S/MIME yang valid dapat memperlihatkan perubahan pada konten yang ditandatangani; fakta bahwa koneksi TLS sebelumnya tidak berhasil. Untuk klien penerima yang disusupi dan memiliki kunci dekripsi, baik enkripsi TLS maupun S/MIME tidak mencegah klien mengakses teks biasa. Untuk metadata perutean dan header luar yang terlihat, jangan menjanjikan penyembunyian total: cakupan bergantung pada pengemasan dan implementasi pesan.
Bukti tinjauan pribadi berisi matriks jalur dan ancaman eksplisit yang menggambarkan batasan-batasan ini. Ini adalah model desain, bukan uji interoperabilitas kriptografi. Lokal TLSA perlengkapan sertifikat di tempat lain dalam paket tidak membentuk perilaku penandatanganan atau dekripsi S/MIME .
Pilih kontrol dan bukti penerimaan bersama-sama
Referensi: RFC 8551 §4, RFC 8551 §6.
Tentukan hop mana yang memerlukan TLS yang diterapkan, konten mana yang memerlukan penandatanganan atau enkripsi, dan di mana dekripsi diizinkan. Uji perwakilan klien, lampiran, penerusan, dan akses arsip dalam lingkungan terkendali. Pertahankan verifikasi positif dan kasus perubahan konten negatif sebelum mengklaim alur kerja menjaga tanda tangan atau kerahasiaan di seluruh rute tertentu.
Menyimpan phishing and business-process claims separate. Pengirim yang diautentikasi atau pesan yang ditandatangani masih dapat berisi permintaan pembayaran yang salah atau menipu, terutama setelah akun disusupi. Verifikasi independen atas tindakan konsekuensial masih diperlukan. Tidak ada pesan S/MIME yang ditandatangani, dienkripsi, dikirimkan atau didekripsi untuk panduan ini; buktinya adalah matriks pengendalian terhadap ancaman yang dapat diperiksa, dan interoperabilitas klien masih merupakan tugas penerimaan yang secara eksplisit tertunda.