S/MIME adalah metode yang telah lama digunakan untuk mengirim email yang dienkripsi dan ditandatangani, berdasarkan standar Internet publik. Kami sering menemukan kebutuhan untuk S/MIME, terutama dari industri yang diatur seperti perbankan, kesehatan, dan keuangan.
Business in a box.
Temukan solusi kami.
Bicaralah kepada tim penjualan kami
S/MIME adalah metode lama untuk mengirim email terenkripsi dan ditandatangani, berdasarkan standar Internet publik. Kami secara teratur menemukan kebutuhan untuk S/MIME, terutama dari industri yang diatur seperti perbankan, kesehatan, dan keuangan. S/MIME sering diperlukan ketika berkomunikasi antara bisnis dan agen pemerintah, misalnya.
Standar email aman lainnya, PGP (secara lucu disebut sebagai “Pretty Good Privacy”), lebih sering digunakan untuk komunikasi aman dari orang ke orang. Ini kurang populer sekarang karena versi konsumen dari klien email berbasis web populer seperti Gmail dan Outlook/Hotmail tidak dapat menampilkan email terenkripsi. Itu salah satu alasan komunikasi dari orang ke orang yang memerlukan privasi telah berpindah ke platform seperti WhatsApp (dan banyak lainnya) yang menawarkan enkripsi end-to-end bawaan.
Baik PGP maupun S/MIME memerlukan klien email yang dapat menggunakan kunci dan sertifikat. Banyak klien desktop dan seluler, termasuk Apple Mail, Microsoft Outlook, dan Mozilla Thunderbird memenuhi kebutuhan, seperti halnya versi bisnis dari beberapa klien web seperti Microsoft Office 365. Menyiapkan kunci membutuhkan usaha, tetapi banyak organisasi masih menganggapnya bermanfaat, meskipun ada pengungkapan kerentanan baru-baru ini yang memerlukan solusi untuk memblokir pemuatan konten jarak jauh.
S/MIME telah ada sejak 1995 dan mengalami beberapa revisi; versi saat ini dicakup oleh RFC 5751. Ini memerlukan pertukaran kunci publik, tugas yang tidak sepele yang sering memerlukan dukungan tim IT atau sumber daya serupa. Inilah dimana solusi komersial dari perusahaan seperti mitra SparkPost Virtru dan Echoworkx masuk, membuat keamanan lebih mudah untuk surat bisnis dari orang ke orang (lihat panduan cara SparkPost/Echoworkx kami untuk informasi lebih lanjut).
Meski begitu, mari kita telusuri sedikit lebih dalam tentang S/MIME biasa dan lihat apa yang bisa kita lakukan dengannya.
Mengapa saya harus peduli?
Versi singkatnya:
Enkripsi memberi Anda privasi pesan.
Penandatanganan memberikan Anda otentikasi (dari pengirim), non-repudiasi asal, dan pemeriksaan integritas pesan.
S/MIME bekerja secara berbeda dengan DKIM dan DMARC dan dapat berkoeksistensi dengan mereka.
Privasi
Jika pesan Anda tidak mengandung apa pun yang bersifat pribadi, sensitivitas, atau penting secara hukum, maka Anda mungkin tidak perlu memikirkan tentang S/MIME. Sistem pengiriman email modern seperti SparkPost sudah menggunakan "TLS oportunistik" untuk mengamankan transportasi pesan dari server pengirim ke server penerima.
Bagian "oportunistik" berarti jika server pengirim tidak dapat bernegosiasi koneksi yang aman, kami akan mengirimkan email dalam teks biasa. Ini tidak cocok jika Anda ingin memaksa pesan agar aman sepanjang jalan. Anda dapat melihat penyedia kotak surat mana yang mengklaim mendukung TLS dan mana yang benar-benar melakukannya. Dengan asumsi bahwa server penerima mendukung TLS, pesan Anda diamankan seperti ini:
TLS mengamankan percakapan antar server email (itulah mengapa disebut Transport Layer Security). MIME (termasuk S/MIME) berkaitan dengan isi pesan dan perlakuannya, dan dapat dianggap sebagai bagian dari "lapisan Presentasi".
S/MIME mengamankan isi pesan sepenuhnya (“dari ujung ke ujung”) dari asal pesan hingga klien email penerima, dengan mengenkapsulasi tubuh pesan.
S/MIME mengenkripsi tubuh pesan dengan kunci publik penerima. Tubuh tidak dapat didekodekan tanpa kunci pribadi penerima—tidak oleh siapa pun di "tengah", seperti ISP Anda, SparkPost, atau server email penerima.
Kunci pribadi tidak pernah diungkapkan; itu dijaga dalam wewenang pribadi penerima. Pesan terenkripsi berpindah melalui Internet ke server email penerima. Ketika sampai di kotak masuk penerima, (biasanya secara otomatis) didekripsi dengan kunci pribadi mereka dan menjadi dapat dibaca.
Beberapa hal yang perlu diingat tentang S/MIME:
Enkripsi S/MIME memiliki efek samping dalam mencegah pemindaian pesan masuk berbasis server untuk malware karena muatan pesan berada dalam bentuk terenkripsi dan karenanya tidak dapat dikenali.
Perhatikan bahwa header pesan (Dari:, Kepada:, Subjek:, dll) tidak dienkripsi, jadi isi baris subjek perlu dibuat dengan mempertimbangkan hal itu.
Penandatanganan – otentikasi
S/MIME juga memberi penerima kemampuan untuk memeriksa bahwa identitas pengirim pesan adalah siapa yang mereka katakan.
Email pengirim memiliki sertifikat terlampir, yang, seperti sertifikat di situs web yang aman, dapat dilacak kembali ke otoritas penerbit. Ada deskripsi lengkap dari proses penandatanganan di sini.
Kami akan mengambil pendekatan untuk menandatangani email terlebih dahulu, dan kemudian mengenkripsinya, sehingga prosesnya terlihat seperti ini.
Non-repudiasi
Manfaat lain dari penandatanganan bagi penerima adalah non-repudiasi asal. Pertimbangkan situasi di mana pesan email digunakan untuk menyetujui sebuah kontrak. Penerima menerima kontrak dalam pesan dari pengirim. Jika pengirim kemudian mencoba mengatakan, "Tidak, saya tidak pernah mengirimkan pesan tersebut kepada Anda", maka pesan yang diterima menunjukkan bahwa sertifikat pengirim memang digunakan.
Integritas Pesan
Proses penandatanganan membuat sidik jari dari pesan sumber asli (dikenal sebagai pencernaan pesan), mengenkripsi pencernaan menggunakan kunci pribadi pengirim, dan menyertakannya dalam pesan yang dikirimkan. Klien email penerima dapat mengetahui jika tubuh pesan diubah.
Mungkin Anda akan berkata, "Saya pikir DKIM memberi saya pemeriksaan integritas pesan!" Benar, DKIM menyediakan pemeriksaan integritas tubuh pesan dan header pesan – jaminan anti-pengubahan. Namun, kegagalan DKIM (atau ketidakhadiran) biasanya tidak akan menyebabkan pesan masuk ditandai sepenuhnya tidak valid, …kecuali jika kebijakan DMARC `p=reject` sedang diterapkan (lebih lanjut tentang DMARC di sini). DKIM adalah satu faktor dari banyak yang digunakan oleh ISP untuk penugasan reputasi yang andal kepada suatu domain dan tentu saja merupakan bagian penting dari stack pesan Anda.
Klien email Anda akan menunjukkan dengan jelas jika pesan S/MIME gagal dalam pemeriksaan tanda tangan:
Ringkasan: ujung-ke-ujung (S/MIME) vs server-ke-server (DKIM, DMARC, TLS)
S/MIME adalah kemampuan lapisan presentasi yang dapat bekerja antara dua pengguna akhir email (dengan sertifikat/kunci yang valid) tanpa tindakan dari admin email. S/MIME menyediakan enkripsi dan penandatanganan dan bersifat pribadi untuk setiap pengguna.
S/MIME terkait dengan alamat pengirim penuh (bagian lokal dan bagian domain), jadi, misalnya, alice@bigcorp.com dan bob@bigcorp.com perlu memiliki sertifikat yang berbeda. Sebaliknya, DKIM memvalidasi email berasal dari domain penandatanganan. DKIM adalah topik tersendiri; artikel ini adalah tempat yang bagus untuk memulai.
DKIM dan DMARC penyiapan dilakukan oleh admin email Anda (bekerja pada server email dan catatan DNS). Setelah diatur, mereka aktif untuk domain, bukan pengguna individu.
Bagaimana hal ini berhubungan dengan SparkPost?
Klien mana yang mendukung S/MIME?
Consumer Gmail
Klien web Gmail biasa menampilkan tanda tangan email yang masuk (lihat di bawah), tetapi tidak diatur untuk menyimpan kunci pribadi Anda untuk membaca pesan terenkripsi. Bahkan jika itu mungkin melalui plugin pihak ketiga, mengunggah kunci pribadi Anda bukan ide yang baik dari sudut pandang keamanan.
Saya tidak bisa membuat Yahoo! Mail mendekode tanda tangan dalam pesan sama sekali.
Versi konsumen dari akun Microsoft Outlook/Hotmail memberi tahu Anda tentang keberadaan tanda tangan S/MIME, tetapi tidak memberi Anda akses penuh untuk melihat atau memeriksa sertifikat.
Hosted business mail
Untuk organisasi dengan mail yang dihosting, Microsoft Office 365 dan G Suite Enterprise memiliki dukungan S/MIME.
Outlook mail clients
Klien berbasis Microsoft Outlook (misalnya 2010 untuk Windows) berfungsi:
Klik pada ikon memberikan Anda informasi lebih lanjut:
Pada Outlook 2010 / Windows, penyimpanan sertifikat diakses melalui File / Options / Trust Center / Trust Center Settings / Email Security / Import / Export.
Thunderbird – cross-platform and free
Jika Anda mencari klien gratis, Mozilla Thunderbird cocok untuk Anda. Tersedia di PC, Mac, dan Linux, serta mendukung S/MIME di semua platform ini. Berikut adalah tampilan pesan di Mac. Ikon "amplop tertutup" menunjukkan pesan ditandatangani, dan gembok menunjukkan pesan terenkripsi.
Klik pada amplop/gembok menunjukkan info tentang pesan:
Thunderbird memiliki penyimpanan kuncinya sendiri, diakses dengan cara yang sama di setiap platform:
Mac melalui Preferences / Advanced / Certificates / Manage Certificates
PC: menu (“hamburger” kanan atas), Advanced / Certificates / Manage Certificates
Linux: menu (“hamburger” kanan atas), Preferences / Advanced / Manage Certificates
Mac Mail
Mac Mail juga mendukung S/MIME. Ini bergantung pada rantai kunci Mac Anda untuk menyimpan kunci Anda.
iOS Mail
Pertama, impor sertifikat akun email Anda seperti ini, kemudian Anda dapat melihat email yang ditandatangani dan terenkripsi S/MIME. Mereka tidak benar-benar terlihat berbeda di layar tampilan.
Android
Beberapa perangkat dan aplikasi mendukung S/MIME; ada banyak variasi di luar sana. Samsung memiliki panduan.
Akhirnya...
Itulah gambaran umum cepat kami tentang penggunaan praktis S/MIME. Jika Anda ingin mendapatkan sertifikat surat Anda sendiri, ada daftar penyedia di sini. Saya menemukan Comodo bekerja dengan baik (gratis untuk penggunaan non-komersial – buka ini di Firefox, bukan Chrome).
Pada bagian 2, kita akan menjelajahi bagaimana menerapkan penandatanganan dan enkripsi S/MIME ke pesan yang Anda kirimkan melalui SparkPost.
Bacaan lebih lanjut
Microsoft memiliki artikel pengantar yang baik tentang S/MIME di sini.
Untuk info lebih lanjut tentang kerentanan EFAIL dan bagaimana hal itu telah diatasi, ini adalah situs definitif. Penjelasan lain yang mudah diikuti ada di sini dan di sini.
