S/MIME: Apa itu, mengapa saya harus peduli, dan bagaimana hubungannya dengan SparkPost?
Burung
19 Des 2018
1 min read
Poin Penting
Pemahaman: S/MIME (Secure/Multipurpose Internet Mail Extensions) adalah standar yang telah ada lama untuk mengirim email yang ditandatangani dan terenkripsi—penting untuk industri yang menangani data sensitif seperti keuangan, kesehatan, dan pemerintahan.
Tujuan: Menjelaskan apa yang dilakukan S/MIME, mengapa itu penting, bagaimana perbedaannya dari DKIM/DMARC/TLS, dan bagaimana ia terintegrasi dengan SparkPost.
Sorotan:
Definisi: S/MIME memungkinkan dua kemampuan inti:
Enkripsi → Melindungi konten pesan (privasi).
Penandatanganan → Mengonfirmasi identitas pengirim, mencegah perubahan, dan memastikan tidak ada penolakan.
Penggunaan industri: Diperlukan atau diutamakan oleh sektor yang diatur yang membutuhkan privasi pesan end-to-end dan identitas yang dapat diverifikasi.
Perbandingan dengan perlindungan email lainnya:
TLS: Mengamankan transmisi antar server (lapisan transportasi).
S/MIME: Mengamankan konten pesan itu sendiri (lapisan presentasi).
DKIM/DMARC: Mengautentikasi domain, bukan individu, dan bekerja di tingkat admin/server.
Mekanisme:
Memanfaatkan pasangan kunci publik/pribadi dan sertifikat digital yang dikeluarkan per identitas email (misalnya, alice@company.com).
Memerlukan klien email yang didukung (Apple Mail, Outlook, Thunderbird, iOS Mail, dll.).
Limitasi:
Kunci dan sertifikat dapat rumit untuk dikelola.
Muatan terenkripsi tidak dapat dipindai untuk malware.
Header (Dari, Ke, Subjek) tetap terlihat.
Integrasi dengan SparkPost:
Pengguna SparkPost dapat menandatangani pesan dengan S/MIME untuk autentikasi yang lebih.
Untuk pengiriman terenkripsi, penerima harus terlebih dahulu membagikan kunci publik mereka (misalnya, dengan mengirimkan pesan yang ditandatangani).
Mitra komersial seperti Virtru dan Echoworx menyederhanakan hal ini untuk alur kerja perusahaan.
Langkah selanjutnya:
Bagian 2 dari seri ini menunjukkan cara menandatangani dan mengenkripsi pesan melalui SparkPost.
Bagian-bagian selanjutnya menunjukkan penyiapan di tempat menggunakan PowerMTA dan Momentum.
Sorotan Tanya jawab
Mengapa S/MIME penting jika saya sudah menggunakan TLS atau DKIM?
TLS melindungi koneksi antara server, sementara S/MIME melindungi konten itu sendiri—memastikan tetap pribadi dan dapat diverifikasi bahkan setelah pengiriman.
Siapa yang paling membutuhkan S/MIME?
Industri yang diatur (keuangan, pemerintahan, kesehatan) dan organisasi manapun yang mengirim email yang bersifat rahasia, mengikat secara hukum, atau sensitif terhadap identitas.
Masalah apa yang diselesaikan oleh S/MIME?
Ini mencegah penyadapan dan pemalsuan, menjamin keaslian pengirim, dan memberikan bukti bahwa pesan tidak diubah.
Apakah SparkPost secara native mendukung S/MIME?
SparkPost mendukung pengiriman pesan yang diformat S/MIME; Anda hanya perlu menandatangani/meng-enkripsi konten Anda sebelum mengirim melalui API atau SMTP.
Bagaimana cara saya mendapatkan sertifikat?
Sertifikat dapat diterbitkan oleh penyedia seperti Comodo (gratis untuk penggunaan non-komersial) atau ditandatangani sendiri untuk pengujian internal.
Apa yang harus saya lakukan jika penerima saya tidak dapat membaca email yang dienkripsi?
Mereka masih akan melihat header pesan yang ditandatangani, tetapi untuk mendekripsi, mereka harus menginstal klien yang kompatibel dan memiliki kunci pribadi mereka yang diimpor.
Bagaimana pertukaran kunci ditangani untuk email yang dihasilkan aplikasi?
Penerima dapat mengirim email ke layanan Anda dengan pesan yang ditandatangani; kunci publik mereka kemudian dapat diekstrak secara otomatis melalui webhook relai masuk.
S/MIME adalah metode yang sudah lama digunakan untuk mengirim email yang terenkripsi dan ditandatangani, berdasarkan standar publik Internet. Kami sering menemui persyaratan untuk S/MIME, terutama dari industri yang diatur seperti perbankan, kesehatan, dan keuangan. S/MIME seringkali diperlukan ketika berkomunikasi antara bisnis dan lembaga pemerintah, misalnya.
Standar email aman lainnya, PGP (dengan nama lucu “Pretty Good Privacy”), lebih banyak digunakan untuk komunikasi aman antar individu. Ini kurang populer sekarang karena versi konsumen dari klien email berbasis web yang populer seperti Gmail dan Outlook/Hotmail tidak dapat menampilkan email yang terenkripsi. Itulah salah satu alasan mengapa banyak komunikasi antar individu yang memerlukan privasi telah pindah ke platform seperti WhatsApp (dan banyak lainnya) yang menawarkan enkripsi end-to-end secara native.
Baik PGP maupun S/MIME memerlukan klien email yang dapat menggunakan kunci dan sertifikat. Banyak klien desktop dan mobile, termasuk Apple Mail, Microsoft Outlook, dan Mozilla Thunderbird memenuhi syarat, begitu pula dengan versi bisnis dari beberapa klien web seperti Microsoft Office 365. Mengatur kunci memerlukan usaha, tetapi banyak organisasi masih menganggapnya bermanfaat, meskipun baru-baru ini terjadi pengungkapan kerentanan yang memerlukan obat untuk memblokir pemuatan konten jarak jauh.
S/MIME telah ada sejak 1995 dan telah melalui beberapa revisi; versi saat ini diatur oleh RFC 5751. Ini memerlukan pertukaran kunci publik, tugas yang tidak sepele yang seringkali memerlukan dukungan dari tim TI atau sumber daya serupa. Untuk organisasi yang menjalankan infrastruktur email on-premises, penerapan S/MIME memerlukan pertimbangan tambahan untuk platform seperti PowerMTA dan Momentum, yang kami bahas dalam panduan kami tentang S/MIME untuk email aman on-premises. Namun, ada pendekatan otomatis untuk memperlancar proses ini, seperti mengumpulkan kunci publik penerima melalui sistem berbasis email yang dapat menyederhanakan manajemen kunci untuk aliran email yang dihasilkan aplikasi. Di sinilah solusi komersial dari perusahaan seperti mitra SparkPost Virtru dan Echoworkx berperan, membuat keamanan lebih mudah untuk pengiriman email bisnis antar individu (lihat panduan SparkPost/Echoworkx kami untuk informasi lebih lanjut).
Itu dikatakan, mari kita gali lebih dalam tentang S/MIME yang biasa dan lihat apa yang bisa kita lakukan dengannya.
S/MIME adalah metode yang sudah lama digunakan untuk mengirim email yang terenkripsi dan ditandatangani, berdasarkan standar publik Internet. Kami sering menemui persyaratan untuk S/MIME, terutama dari industri yang diatur seperti perbankan, kesehatan, dan keuangan. S/MIME seringkali diperlukan ketika berkomunikasi antara bisnis dan lembaga pemerintah, misalnya.
Standar email aman lainnya, PGP (dengan nama lucu “Pretty Good Privacy”), lebih banyak digunakan untuk komunikasi aman antar individu. Ini kurang populer sekarang karena versi konsumen dari klien email berbasis web yang populer seperti Gmail dan Outlook/Hotmail tidak dapat menampilkan email yang terenkripsi. Itulah salah satu alasan mengapa banyak komunikasi antar individu yang memerlukan privasi telah pindah ke platform seperti WhatsApp (dan banyak lainnya) yang menawarkan enkripsi end-to-end secara native.
Baik PGP maupun S/MIME memerlukan klien email yang dapat menggunakan kunci dan sertifikat. Banyak klien desktop dan mobile, termasuk Apple Mail, Microsoft Outlook, dan Mozilla Thunderbird memenuhi syarat, begitu pula dengan versi bisnis dari beberapa klien web seperti Microsoft Office 365. Mengatur kunci memerlukan usaha, tetapi banyak organisasi masih menganggapnya bermanfaat, meskipun baru-baru ini terjadi pengungkapan kerentanan yang memerlukan obat untuk memblokir pemuatan konten jarak jauh.
S/MIME telah ada sejak 1995 dan telah melalui beberapa revisi; versi saat ini diatur oleh RFC 5751. Ini memerlukan pertukaran kunci publik, tugas yang tidak sepele yang seringkali memerlukan dukungan dari tim TI atau sumber daya serupa. Untuk organisasi yang menjalankan infrastruktur email on-premises, penerapan S/MIME memerlukan pertimbangan tambahan untuk platform seperti PowerMTA dan Momentum, yang kami bahas dalam panduan kami tentang S/MIME untuk email aman on-premises. Namun, ada pendekatan otomatis untuk memperlancar proses ini, seperti mengumpulkan kunci publik penerima melalui sistem berbasis email yang dapat menyederhanakan manajemen kunci untuk aliran email yang dihasilkan aplikasi. Di sinilah solusi komersial dari perusahaan seperti mitra SparkPost Virtru dan Echoworkx berperan, membuat keamanan lebih mudah untuk pengiriman email bisnis antar individu (lihat panduan SparkPost/Echoworkx kami untuk informasi lebih lanjut).
Itu dikatakan, mari kita gali lebih dalam tentang S/MIME yang biasa dan lihat apa yang bisa kita lakukan dengannya.
S/MIME adalah metode yang sudah lama digunakan untuk mengirim email yang terenkripsi dan ditandatangani, berdasarkan standar publik Internet. Kami sering menemui persyaratan untuk S/MIME, terutama dari industri yang diatur seperti perbankan, kesehatan, dan keuangan. S/MIME seringkali diperlukan ketika berkomunikasi antara bisnis dan lembaga pemerintah, misalnya.
Standar email aman lainnya, PGP (dengan nama lucu “Pretty Good Privacy”), lebih banyak digunakan untuk komunikasi aman antar individu. Ini kurang populer sekarang karena versi konsumen dari klien email berbasis web yang populer seperti Gmail dan Outlook/Hotmail tidak dapat menampilkan email yang terenkripsi. Itulah salah satu alasan mengapa banyak komunikasi antar individu yang memerlukan privasi telah pindah ke platform seperti WhatsApp (dan banyak lainnya) yang menawarkan enkripsi end-to-end secara native.
Baik PGP maupun S/MIME memerlukan klien email yang dapat menggunakan kunci dan sertifikat. Banyak klien desktop dan mobile, termasuk Apple Mail, Microsoft Outlook, dan Mozilla Thunderbird memenuhi syarat, begitu pula dengan versi bisnis dari beberapa klien web seperti Microsoft Office 365. Mengatur kunci memerlukan usaha, tetapi banyak organisasi masih menganggapnya bermanfaat, meskipun baru-baru ini terjadi pengungkapan kerentanan yang memerlukan obat untuk memblokir pemuatan konten jarak jauh.
S/MIME telah ada sejak 1995 dan telah melalui beberapa revisi; versi saat ini diatur oleh RFC 5751. Ini memerlukan pertukaran kunci publik, tugas yang tidak sepele yang seringkali memerlukan dukungan dari tim TI atau sumber daya serupa. Untuk organisasi yang menjalankan infrastruktur email on-premises, penerapan S/MIME memerlukan pertimbangan tambahan untuk platform seperti PowerMTA dan Momentum, yang kami bahas dalam panduan kami tentang S/MIME untuk email aman on-premises. Namun, ada pendekatan otomatis untuk memperlancar proses ini, seperti mengumpulkan kunci publik penerima melalui sistem berbasis email yang dapat menyederhanakan manajemen kunci untuk aliran email yang dihasilkan aplikasi. Di sinilah solusi komersial dari perusahaan seperti mitra SparkPost Virtru dan Echoworkx berperan, membuat keamanan lebih mudah untuk pengiriman email bisnis antar individu (lihat panduan SparkPost/Echoworkx kami untuk informasi lebih lanjut).
Itu dikatakan, mari kita gali lebih dalam tentang S/MIME yang biasa dan lihat apa yang bisa kita lakukan dengannya.
Mengapa saya harus peduli?
Versi singkat:
Enkripsi memberikan privasi pesan kepada Anda.
Penandatanganan memberi Anda otentikasi (pengirim), penolakan asal, dan pemeriksaan integritas pesan.
S/MIME bekerja berbeda dari DKIM dan DMARC dan dapat coexist dengan mereka.
Privasi
Jika pesan Anda tidak mengandung apapun yang bersifat pribadi, pribadi, atau penting secara hukum, maka Anda mungkin tidak perlu memikirkan S/MIME. Sistem pengiriman email modern seperti SparkPost sudah menggunakan "TLS oportunistik" untuk mengamankan transportasi pesan dari server pengirim ke server penerima.
Bagian "opportunistik" memang berarti bahwa jika server pengirim tidak dapat bernegosiasi untuk koneksi yang aman, kami akan mengirim email dalam bentuk teks biasa. Ini tidak cocok jika Anda ingin memaksa pesan agar aman sepanjang jalan. Anda dapat melihat provider kotak surat mana yang mengklaim dukungan TLS dan mana yang benar-benar melakukannya. Dengan asumsi server penerima mendukung TLS, pesan Anda diamankan seperti ini:
TLS mengamankan percakapan antara server email (itulah mengapa disebut Transport Layer Security). MIME (termasuk S/MIME) memperhatikan konten pesan dan perlakuannya, dan dapat dianggap sebagai bagian dari "lapisan presentasi".
S/MIME mengamankan isi pesan sepenuhnya ("end to end") dari asal pesan hingga klien email penerima, mengenkapsulasi isi pesan.
S/MIME mengenkripsi isi pesan dengan kunci publik penerima. Isi tidak dapat didekode tanpa kunci pribadi penerima—tidak oleh "orang di tengah" seperti ISP Anda, SparkPost, atau server email penerima.
Kunci pribadi tidak pernah diungkapkan; itu disimpan dalam kepemilikan eksklusif penerima. Pesan yang terenskripsi bepergian melalui Internet ke server email penerima. Ketika tiba di kotak surat penerima, biasanya akan terdekripsi secara otomatis dengan kunci pribadi mereka dan menjadi terbaca.
Beberapa hal yang perlu diperhatikan terkait S/MIME:
Enkripsi S/MIME memiliki efek samping yang mencegah pemindaian pesan masuk berbasis server untuk perangkat lunak jahat karena muatan pesan berada dalam bentuk terenkripsi dan karena itu tidak dapat diidentifikasi.
Perhatikan bahwa header pesan (Dari:, Untuk:, Subjek: dll) tidak dienkripsi, jadi konten baris subjek perlu dibuat dengan memperhatikan hal itu.
Penandatanganan – otentikasi
S/MIME juga memberikan kemampuan kepada penerima untuk memeriksa bahwa identitas pengirim pesan adalah seperti yang mereka katakan.
Email pengirim disertai dengan sertifikat, yang, mirip seperti sertifikat di situs web yang aman, dapat dilacak kembali ke otoritas penerbit. Untuk deskripsi lengkap tentang proses penandatanganan, lihat PDF proses penandatanganan S/MIME.
Kami akan mengambil pendekatan untuk menandatangani email terlebih dahulu, dan kemudian mengenkripsinya, sehingga prosesnya terlihat seperti ini.
Non-penolakan
Manfaat berguna lain dari penandatanganan bagi penerima adalah non-penolakan asal. Pertimbangkan situasi di mana pesan email digunakan untuk menyetujui suatu kontrak. Penerima mendapatkan kontrak dalam pesan dari pengirim. Jika pengirim kemudian mencoba untuk berkata, "Tidak, saya tidak pernah mengirimkan pesan itu kepada Anda", maka pesan yang diterima menunjukkan bahwa sertifikat pengirim memang digunakan.
Integritas pesan
Proses penandatanganan membuat sidik jari dari pesan sumber biasa (dikenal sebagai ringkasan pesan), mengenkripsi ringkasan menggunakan kunci pribadi pengirim, dan menyertakannya dalam pesan yang dikirimkan. Klien email penerima dapat memberi tahu jika isi pesan telah dirusak.
Mungkin Anda akan berkata, "Saya pikir DKIM memberi saya pemeriksaan integritas pesan!" Yah, ya, DKIM menyediakan pemeriksaan integritas isi pesan dan header pesan – jaminan anti-penyalahgunaan. Namun, kegagalan DKIM (atau ketidakhadiran) biasanya tidak akan menyebabkan pesan masuk untuk ditandai sebagai tidak valid sepenuhnya … kecuali jika kebijakan DMARC p=tolak diberlakukan (lihat postingan blog kami DMARC: Cara Melindungi Reputasi Email Anda). DKIM adalah satu faktor dari banyak yang digunakan oleh ISP untuk penugasan reputasi yang dapat diandalkan ke suatu domain dan merupakan, tentu saja, bagian penting dari tumpukan pesan Anda.
Klien email Anda akan menunjukkan dengan jelas jika pesan S/MIME gagal pemeriksaan tanda tangan:
Ringkasan: end-to-end (S/MIME) vs server-to-server (DKIM, DMARC, TLS)
S/MIME adalah kemampuan lapisan presentasi yang dapat bekerja antara dua pengguna email (dengan sertifikat/kunci yang valid) tanpa adanya tindakan dari admin email. S/MIME menyediakan enkripsi dan penandatanganan dan bersifat personal untuk setiap pengguna.
S/MIME terikat pada alamat pengiriman penuh (bagian lokal dan bagian domain), jadi, misalnya, alice@bigcorp.com dan bob@bigcorp.com harus memiliki sertifikat yang berbeda. Sebaliknya, DKIM memvalidasi bahwa email berasal dari domain yang menandatangani. DKIM adalah topik tersendiri; artikel ini adalah tempat yang baik untuk memulai.
Pengaturan DKIM dan DMARC dilakukan oleh admin email Anda (bekerja di server email dan catatan DNS). Setelah diatur, mereka aktif untuk domain, bukan untuk pengguna individual.
Versi singkat:
Enkripsi memberikan privasi pesan kepada Anda.
Penandatanganan memberi Anda otentikasi (pengirim), penolakan asal, dan pemeriksaan integritas pesan.
S/MIME bekerja berbeda dari DKIM dan DMARC dan dapat coexist dengan mereka.
Privasi
Jika pesan Anda tidak mengandung apapun yang bersifat pribadi, pribadi, atau penting secara hukum, maka Anda mungkin tidak perlu memikirkan S/MIME. Sistem pengiriman email modern seperti SparkPost sudah menggunakan "TLS oportunistik" untuk mengamankan transportasi pesan dari server pengirim ke server penerima.
Bagian "opportunistik" memang berarti bahwa jika server pengirim tidak dapat bernegosiasi untuk koneksi yang aman, kami akan mengirim email dalam bentuk teks biasa. Ini tidak cocok jika Anda ingin memaksa pesan agar aman sepanjang jalan. Anda dapat melihat provider kotak surat mana yang mengklaim dukungan TLS dan mana yang benar-benar melakukannya. Dengan asumsi server penerima mendukung TLS, pesan Anda diamankan seperti ini:
TLS mengamankan percakapan antara server email (itulah mengapa disebut Transport Layer Security). MIME (termasuk S/MIME) memperhatikan konten pesan dan perlakuannya, dan dapat dianggap sebagai bagian dari "lapisan presentasi".
S/MIME mengamankan isi pesan sepenuhnya ("end to end") dari asal pesan hingga klien email penerima, mengenkapsulasi isi pesan.
S/MIME mengenkripsi isi pesan dengan kunci publik penerima. Isi tidak dapat didekode tanpa kunci pribadi penerima—tidak oleh "orang di tengah" seperti ISP Anda, SparkPost, atau server email penerima.
Kunci pribadi tidak pernah diungkapkan; itu disimpan dalam kepemilikan eksklusif penerima. Pesan yang terenskripsi bepergian melalui Internet ke server email penerima. Ketika tiba di kotak surat penerima, biasanya akan terdekripsi secara otomatis dengan kunci pribadi mereka dan menjadi terbaca.
Beberapa hal yang perlu diperhatikan terkait S/MIME:
Enkripsi S/MIME memiliki efek samping yang mencegah pemindaian pesan masuk berbasis server untuk perangkat lunak jahat karena muatan pesan berada dalam bentuk terenkripsi dan karena itu tidak dapat diidentifikasi.
Perhatikan bahwa header pesan (Dari:, Untuk:, Subjek: dll) tidak dienkripsi, jadi konten baris subjek perlu dibuat dengan memperhatikan hal itu.
Penandatanganan – otentikasi
S/MIME juga memberikan kemampuan kepada penerima untuk memeriksa bahwa identitas pengirim pesan adalah seperti yang mereka katakan.
Email pengirim disertai dengan sertifikat, yang, mirip seperti sertifikat di situs web yang aman, dapat dilacak kembali ke otoritas penerbit. Untuk deskripsi lengkap tentang proses penandatanganan, lihat PDF proses penandatanganan S/MIME.
Kami akan mengambil pendekatan untuk menandatangani email terlebih dahulu, dan kemudian mengenkripsinya, sehingga prosesnya terlihat seperti ini.
Non-penolakan
Manfaat berguna lain dari penandatanganan bagi penerima adalah non-penolakan asal. Pertimbangkan situasi di mana pesan email digunakan untuk menyetujui suatu kontrak. Penerima mendapatkan kontrak dalam pesan dari pengirim. Jika pengirim kemudian mencoba untuk berkata, "Tidak, saya tidak pernah mengirimkan pesan itu kepada Anda", maka pesan yang diterima menunjukkan bahwa sertifikat pengirim memang digunakan.
Integritas pesan
Proses penandatanganan membuat sidik jari dari pesan sumber biasa (dikenal sebagai ringkasan pesan), mengenkripsi ringkasan menggunakan kunci pribadi pengirim, dan menyertakannya dalam pesan yang dikirimkan. Klien email penerima dapat memberi tahu jika isi pesan telah dirusak.
Mungkin Anda akan berkata, "Saya pikir DKIM memberi saya pemeriksaan integritas pesan!" Yah, ya, DKIM menyediakan pemeriksaan integritas isi pesan dan header pesan – jaminan anti-penyalahgunaan. Namun, kegagalan DKIM (atau ketidakhadiran) biasanya tidak akan menyebabkan pesan masuk untuk ditandai sebagai tidak valid sepenuhnya … kecuali jika kebijakan DMARC p=tolak diberlakukan (lihat postingan blog kami DMARC: Cara Melindungi Reputasi Email Anda). DKIM adalah satu faktor dari banyak yang digunakan oleh ISP untuk penugasan reputasi yang dapat diandalkan ke suatu domain dan merupakan, tentu saja, bagian penting dari tumpukan pesan Anda.
Klien email Anda akan menunjukkan dengan jelas jika pesan S/MIME gagal pemeriksaan tanda tangan:
Ringkasan: end-to-end (S/MIME) vs server-to-server (DKIM, DMARC, TLS)
S/MIME adalah kemampuan lapisan presentasi yang dapat bekerja antara dua pengguna email (dengan sertifikat/kunci yang valid) tanpa adanya tindakan dari admin email. S/MIME menyediakan enkripsi dan penandatanganan dan bersifat personal untuk setiap pengguna.
S/MIME terikat pada alamat pengiriman penuh (bagian lokal dan bagian domain), jadi, misalnya, alice@bigcorp.com dan bob@bigcorp.com harus memiliki sertifikat yang berbeda. Sebaliknya, DKIM memvalidasi bahwa email berasal dari domain yang menandatangani. DKIM adalah topik tersendiri; artikel ini adalah tempat yang baik untuk memulai.
Pengaturan DKIM dan DMARC dilakukan oleh admin email Anda (bekerja di server email dan catatan DNS). Setelah diatur, mereka aktif untuk domain, bukan untuk pengguna individual.
Versi singkat:
Enkripsi memberikan privasi pesan kepada Anda.
Penandatanganan memberi Anda otentikasi (pengirim), penolakan asal, dan pemeriksaan integritas pesan.
S/MIME bekerja berbeda dari DKIM dan DMARC dan dapat coexist dengan mereka.
Privasi
Jika pesan Anda tidak mengandung apapun yang bersifat pribadi, pribadi, atau penting secara hukum, maka Anda mungkin tidak perlu memikirkan S/MIME. Sistem pengiriman email modern seperti SparkPost sudah menggunakan "TLS oportunistik" untuk mengamankan transportasi pesan dari server pengirim ke server penerima.
Bagian "opportunistik" memang berarti bahwa jika server pengirim tidak dapat bernegosiasi untuk koneksi yang aman, kami akan mengirim email dalam bentuk teks biasa. Ini tidak cocok jika Anda ingin memaksa pesan agar aman sepanjang jalan. Anda dapat melihat provider kotak surat mana yang mengklaim dukungan TLS dan mana yang benar-benar melakukannya. Dengan asumsi server penerima mendukung TLS, pesan Anda diamankan seperti ini:
TLS mengamankan percakapan antara server email (itulah mengapa disebut Transport Layer Security). MIME (termasuk S/MIME) memperhatikan konten pesan dan perlakuannya, dan dapat dianggap sebagai bagian dari "lapisan presentasi".
S/MIME mengamankan isi pesan sepenuhnya ("end to end") dari asal pesan hingga klien email penerima, mengenkapsulasi isi pesan.
S/MIME mengenkripsi isi pesan dengan kunci publik penerima. Isi tidak dapat didekode tanpa kunci pribadi penerima—tidak oleh "orang di tengah" seperti ISP Anda, SparkPost, atau server email penerima.
Kunci pribadi tidak pernah diungkapkan; itu disimpan dalam kepemilikan eksklusif penerima. Pesan yang terenskripsi bepergian melalui Internet ke server email penerima. Ketika tiba di kotak surat penerima, biasanya akan terdekripsi secara otomatis dengan kunci pribadi mereka dan menjadi terbaca.
Beberapa hal yang perlu diperhatikan terkait S/MIME:
Enkripsi S/MIME memiliki efek samping yang mencegah pemindaian pesan masuk berbasis server untuk perangkat lunak jahat karena muatan pesan berada dalam bentuk terenkripsi dan karena itu tidak dapat diidentifikasi.
Perhatikan bahwa header pesan (Dari:, Untuk:, Subjek: dll) tidak dienkripsi, jadi konten baris subjek perlu dibuat dengan memperhatikan hal itu.
Penandatanganan – otentikasi
S/MIME juga memberikan kemampuan kepada penerima untuk memeriksa bahwa identitas pengirim pesan adalah seperti yang mereka katakan.
Email pengirim disertai dengan sertifikat, yang, mirip seperti sertifikat di situs web yang aman, dapat dilacak kembali ke otoritas penerbit. Untuk deskripsi lengkap tentang proses penandatanganan, lihat PDF proses penandatanganan S/MIME.
Kami akan mengambil pendekatan untuk menandatangani email terlebih dahulu, dan kemudian mengenkripsinya, sehingga prosesnya terlihat seperti ini.
Non-penolakan
Manfaat berguna lain dari penandatanganan bagi penerima adalah non-penolakan asal. Pertimbangkan situasi di mana pesan email digunakan untuk menyetujui suatu kontrak. Penerima mendapatkan kontrak dalam pesan dari pengirim. Jika pengirim kemudian mencoba untuk berkata, "Tidak, saya tidak pernah mengirimkan pesan itu kepada Anda", maka pesan yang diterima menunjukkan bahwa sertifikat pengirim memang digunakan.
Integritas pesan
Proses penandatanganan membuat sidik jari dari pesan sumber biasa (dikenal sebagai ringkasan pesan), mengenkripsi ringkasan menggunakan kunci pribadi pengirim, dan menyertakannya dalam pesan yang dikirimkan. Klien email penerima dapat memberi tahu jika isi pesan telah dirusak.
Mungkin Anda akan berkata, "Saya pikir DKIM memberi saya pemeriksaan integritas pesan!" Yah, ya, DKIM menyediakan pemeriksaan integritas isi pesan dan header pesan – jaminan anti-penyalahgunaan. Namun, kegagalan DKIM (atau ketidakhadiran) biasanya tidak akan menyebabkan pesan masuk untuk ditandai sebagai tidak valid sepenuhnya … kecuali jika kebijakan DMARC p=tolak diberlakukan (lihat postingan blog kami DMARC: Cara Melindungi Reputasi Email Anda). DKIM adalah satu faktor dari banyak yang digunakan oleh ISP untuk penugasan reputasi yang dapat diandalkan ke suatu domain dan merupakan, tentu saja, bagian penting dari tumpukan pesan Anda.
Klien email Anda akan menunjukkan dengan jelas jika pesan S/MIME gagal pemeriksaan tanda tangan:
Ringkasan: end-to-end (S/MIME) vs server-to-server (DKIM, DMARC, TLS)
S/MIME adalah kemampuan lapisan presentasi yang dapat bekerja antara dua pengguna email (dengan sertifikat/kunci yang valid) tanpa adanya tindakan dari admin email. S/MIME menyediakan enkripsi dan penandatanganan dan bersifat personal untuk setiap pengguna.
S/MIME terikat pada alamat pengiriman penuh (bagian lokal dan bagian domain), jadi, misalnya, alice@bigcorp.com dan bob@bigcorp.com harus memiliki sertifikat yang berbeda. Sebaliknya, DKIM memvalidasi bahwa email berasal dari domain yang menandatangani. DKIM adalah topik tersendiri; artikel ini adalah tempat yang baik untuk memulai.
Pengaturan DKIM dan DMARC dilakukan oleh admin email Anda (bekerja di server email dan catatan DNS). Setelah diatur, mereka aktif untuk domain, bukan untuk pengguna individual.
Bagaimana ini terkait dengan SparkPost?
Sistem email untuk pesan antar pribadi, seperti Microsoft Exchange Server, telah lama mendukung S/MIME.
Jika Anda menggunakan SparkPost untuk mengirim kepada penerima tertentu dengan klien email yang dapat membaca S/MIME, maka mungkin masuk akal untuk menandatangani pesan Anda dengan S/MIME. Penandatanganan S/MIME menambah jaminan lebih lanjut bahwa pesan tersebut benar-benar berasal dari Anda (atau sistem Anda), dan tidak telah diubah, yang mungkin berharga dalam beberapa penggunaan. Yang Anda butuhkan hanyalah kunci Anda sendiri dan beberapa perangkat lunak gratis yang akan kami demokan di bagian 2 artikel ini.
Menggunakan enkripsi S/MIME adalah pilihan terpisah yang harus dibuat. Anda akan memerlukan kunci publik untuk setiap penerima Anda. Mendapatkannya bisa semudah meminta mereka mengirimkan email yang ditandatangani kepada Anda (atau aplikasi Anda). Kami akan mengeksplorasi alat praktis untuk mengirim email S/MIME yang ditandatangani dan dienkripsi melalui SparkPost dalam posting lanjutan.
Sistem email untuk pesan antar pribadi, seperti Microsoft Exchange Server, telah lama mendukung S/MIME.
Jika Anda menggunakan SparkPost untuk mengirim kepada penerima tertentu dengan klien email yang dapat membaca S/MIME, maka mungkin masuk akal untuk menandatangani pesan Anda dengan S/MIME. Penandatanganan S/MIME menambah jaminan lebih lanjut bahwa pesan tersebut benar-benar berasal dari Anda (atau sistem Anda), dan tidak telah diubah, yang mungkin berharga dalam beberapa penggunaan. Yang Anda butuhkan hanyalah kunci Anda sendiri dan beberapa perangkat lunak gratis yang akan kami demokan di bagian 2 artikel ini.
Menggunakan enkripsi S/MIME adalah pilihan terpisah yang harus dibuat. Anda akan memerlukan kunci publik untuk setiap penerima Anda. Mendapatkannya bisa semudah meminta mereka mengirimkan email yang ditandatangani kepada Anda (atau aplikasi Anda). Kami akan mengeksplorasi alat praktis untuk mengirim email S/MIME yang ditandatangani dan dienkripsi melalui SparkPost dalam posting lanjutan.
Sistem email untuk pesan antar pribadi, seperti Microsoft Exchange Server, telah lama mendukung S/MIME.
Jika Anda menggunakan SparkPost untuk mengirim kepada penerima tertentu dengan klien email yang dapat membaca S/MIME, maka mungkin masuk akal untuk menandatangani pesan Anda dengan S/MIME. Penandatanganan S/MIME menambah jaminan lebih lanjut bahwa pesan tersebut benar-benar berasal dari Anda (atau sistem Anda), dan tidak telah diubah, yang mungkin berharga dalam beberapa penggunaan. Yang Anda butuhkan hanyalah kunci Anda sendiri dan beberapa perangkat lunak gratis yang akan kami demokan di bagian 2 artikel ini.
Menggunakan enkripsi S/MIME adalah pilihan terpisah yang harus dibuat. Anda akan memerlukan kunci publik untuk setiap penerima Anda. Mendapatkannya bisa semudah meminta mereka mengirimkan email yang ditandatangani kepada Anda (atau aplikasi Anda). Kami akan mengeksplorasi alat praktis untuk mengirim email S/MIME yang ditandatangani dan dienkripsi melalui SparkPost dalam posting lanjutan.
Klien mana yang mendukung S/MIME?
Consumer Gmail
Klien web Gmail biasa menampilkan tanda tangan email masuk (lihat di bawah), tetapi tidak dirancang untuk menyimpan kunci pribadi Anda untuk membaca pesan yang dienkripsi. Bahkan jika itu mungkin melalui plugin pihak ketiga, mengunggah kunci pribadi Anda bukanlah ide yang bagus dari sudut pandang keamanan.
Saya tidak dapat membuat Yahoo! Mail mendekode tanda tangan dalam pesan sama sekali.
Versi konsumen dari akun Microsoft Outlook/Hotmail memberi tahu Anda tentang adanya tanda tangan S/MIME, tetapi tidak memberi Anda akses penuh untuk melihat atau memeriksa sertifikat.
Email bisnis yang dihosting
Untuk organisasi dengan email yang dihosting, Microsoft Office 365 dan G Suite Enterprise memiliki dukungan S/MIME.
Klien email Outlook
Microsoft Outlook berbasis klien (misalnya 2010 untuk Windows) berfungsi:
Klik pada ikon memberikan Anda informasi lebih lanjut:
Di Outlook 2010 / Windows, penyimpanan sertifikat diakses melalui File / Opsi / Pusat Kepercayaan / Pengaturan Pusat Kepercayaan / Keamanan Email / Impor / Ekspor.
Thunderbird – lintas platform dan gratis
Jika Anda mencari klien gratis, Mozilla Thunderbird cocok untuk kebutuhan Anda. Ini tersedia di PC, Mac, dan Linux, dan mendukung S/MIME di semua platform ini. Berikut adalah cara tampil pesan di Mac. Ikon "amplop tertutup" menunjukkan pesan tersebut ditandatangani, dan kunci padlock menunjukkan bahwa pesan tersebut dienkripsi.
Klik pada amplop/kunci padlock menampilkan informasi tentang pesan:
Thunderbird memiliki penyimpanan kunci sendiri, diakses dengan cara serupa di masing-masing platform:
Mac melalui Preferensi / Lanjut / Sertifikat / Kelola Sertifikat
PC: menu (“hamburger” di kanan atas), Lanjut / Sertifikat / Kelola Sertifikat
Linux: menu (“hamburger” di kanan atas), Preferensi / Lanjut / Kelola Sertifikat
Mac Mail
Mac Mail juga mendukung S/MIME. Ini bergantung pada kunci Anda di keychain Mac.
iOS Mail
Pertama, impor sertifikat akun email Anda seperti ini, kemudian Anda dapat melihat email yang ditandatangani dan dienkripsi dengan S/MIME. Mereka tidak terlihat berbeda di layar tampilan.
Android
Beberapa perangkat dan aplikasi mendukung S/MIME; ada banyak variasi di luar sana. Samsung memiliki panduan.
Consumer Gmail
Klien web Gmail biasa menampilkan tanda tangan email masuk (lihat di bawah), tetapi tidak dirancang untuk menyimpan kunci pribadi Anda untuk membaca pesan yang dienkripsi. Bahkan jika itu mungkin melalui plugin pihak ketiga, mengunggah kunci pribadi Anda bukanlah ide yang bagus dari sudut pandang keamanan.
Saya tidak dapat membuat Yahoo! Mail mendekode tanda tangan dalam pesan sama sekali.
Versi konsumen dari akun Microsoft Outlook/Hotmail memberi tahu Anda tentang adanya tanda tangan S/MIME, tetapi tidak memberi Anda akses penuh untuk melihat atau memeriksa sertifikat.
Email bisnis yang dihosting
Untuk organisasi dengan email yang dihosting, Microsoft Office 365 dan G Suite Enterprise memiliki dukungan S/MIME.
Klien email Outlook
Microsoft Outlook berbasis klien (misalnya 2010 untuk Windows) berfungsi:
Klik pada ikon memberikan Anda informasi lebih lanjut:
Di Outlook 2010 / Windows, penyimpanan sertifikat diakses melalui File / Opsi / Pusat Kepercayaan / Pengaturan Pusat Kepercayaan / Keamanan Email / Impor / Ekspor.
Thunderbird – lintas platform dan gratis
Jika Anda mencari klien gratis, Mozilla Thunderbird cocok untuk kebutuhan Anda. Ini tersedia di PC, Mac, dan Linux, dan mendukung S/MIME di semua platform ini. Berikut adalah cara tampil pesan di Mac. Ikon "amplop tertutup" menunjukkan pesan tersebut ditandatangani, dan kunci padlock menunjukkan bahwa pesan tersebut dienkripsi.
Klik pada amplop/kunci padlock menampilkan informasi tentang pesan:
Thunderbird memiliki penyimpanan kunci sendiri, diakses dengan cara serupa di masing-masing platform:
Mac melalui Preferensi / Lanjut / Sertifikat / Kelola Sertifikat
PC: menu (“hamburger” di kanan atas), Lanjut / Sertifikat / Kelola Sertifikat
Linux: menu (“hamburger” di kanan atas), Preferensi / Lanjut / Kelola Sertifikat
Mac Mail
Mac Mail juga mendukung S/MIME. Ini bergantung pada kunci Anda di keychain Mac.
iOS Mail
Pertama, impor sertifikat akun email Anda seperti ini, kemudian Anda dapat melihat email yang ditandatangani dan dienkripsi dengan S/MIME. Mereka tidak terlihat berbeda di layar tampilan.
Android
Beberapa perangkat dan aplikasi mendukung S/MIME; ada banyak variasi di luar sana. Samsung memiliki panduan.
Consumer Gmail
Klien web Gmail biasa menampilkan tanda tangan email masuk (lihat di bawah), tetapi tidak dirancang untuk menyimpan kunci pribadi Anda untuk membaca pesan yang dienkripsi. Bahkan jika itu mungkin melalui plugin pihak ketiga, mengunggah kunci pribadi Anda bukanlah ide yang bagus dari sudut pandang keamanan.
Saya tidak dapat membuat Yahoo! Mail mendekode tanda tangan dalam pesan sama sekali.
Versi konsumen dari akun Microsoft Outlook/Hotmail memberi tahu Anda tentang adanya tanda tangan S/MIME, tetapi tidak memberi Anda akses penuh untuk melihat atau memeriksa sertifikat.
Email bisnis yang dihosting
Untuk organisasi dengan email yang dihosting, Microsoft Office 365 dan G Suite Enterprise memiliki dukungan S/MIME.
Klien email Outlook
Microsoft Outlook berbasis klien (misalnya 2010 untuk Windows) berfungsi:
Klik pada ikon memberikan Anda informasi lebih lanjut:
Di Outlook 2010 / Windows, penyimpanan sertifikat diakses melalui File / Opsi / Pusat Kepercayaan / Pengaturan Pusat Kepercayaan / Keamanan Email / Impor / Ekspor.
Thunderbird – lintas platform dan gratis
Jika Anda mencari klien gratis, Mozilla Thunderbird cocok untuk kebutuhan Anda. Ini tersedia di PC, Mac, dan Linux, dan mendukung S/MIME di semua platform ini. Berikut adalah cara tampil pesan di Mac. Ikon "amplop tertutup" menunjukkan pesan tersebut ditandatangani, dan kunci padlock menunjukkan bahwa pesan tersebut dienkripsi.
Klik pada amplop/kunci padlock menampilkan informasi tentang pesan:
Thunderbird memiliki penyimpanan kunci sendiri, diakses dengan cara serupa di masing-masing platform:
Mac melalui Preferensi / Lanjut / Sertifikat / Kelola Sertifikat
PC: menu (“hamburger” di kanan atas), Lanjut / Sertifikat / Kelola Sertifikat
Linux: menu (“hamburger” di kanan atas), Preferensi / Lanjut / Kelola Sertifikat
Mac Mail
Mac Mail juga mendukung S/MIME. Ini bergantung pada kunci Anda di keychain Mac.
iOS Mail
Pertama, impor sertifikat akun email Anda seperti ini, kemudian Anda dapat melihat email yang ditandatangani dan dienkripsi dengan S/MIME. Mereka tidak terlihat berbeda di layar tampilan.
Android
Beberapa perangkat dan aplikasi mendukung S/MIME; ada banyak variasi di luar sana. Samsung memiliki panduan.
Akhirnya...
Itu adalah gambaran cepat tentang penggunaan praktis S/MIME. Jika Anda ingin mendapatkan sertifikat email Anda sendiri, ada daftar penyedia di sini. Saya menemukan Comodo bekerja dengan baik (gratis untuk penggunaan non-komersial – buka ini di Firefox, bukan Chrome).
Di bagian 2, kita akan menjelajahi bagaimana menerapkan penandatanganan S/MIME dan enkripsi ke pesan yang Anda kirim melalui SparkPost.
Bacaan lebih lanjut
Microsoft memiliki artikel pengantar yang baik tentang S/MIME dalam dokumentasi mereka.
Untuk informasi lebih lanjut tentang kerentanan EFAIL dan bagaimana itu ditangani, lihat situs web resmi EFAIL. Penjelasan lain yang mudah diikuti tersedia di halaman wiki EFAIL dan di posting blog CipherMail EFAIL: Mana yang rentan, PGP, S/MIME atau klien email Anda?.
Itu adalah gambaran cepat tentang penggunaan praktis S/MIME. Jika Anda ingin mendapatkan sertifikat email Anda sendiri, ada daftar penyedia di sini. Saya menemukan Comodo bekerja dengan baik (gratis untuk penggunaan non-komersial – buka ini di Firefox, bukan Chrome).
Di bagian 2, kita akan menjelajahi bagaimana menerapkan penandatanganan S/MIME dan enkripsi ke pesan yang Anda kirim melalui SparkPost.
Bacaan lebih lanjut
Microsoft memiliki artikel pengantar yang baik tentang S/MIME dalam dokumentasi mereka.
Untuk informasi lebih lanjut tentang kerentanan EFAIL dan bagaimana itu ditangani, lihat situs web resmi EFAIL. Penjelasan lain yang mudah diikuti tersedia di halaman wiki EFAIL dan di posting blog CipherMail EFAIL: Mana yang rentan, PGP, S/MIME atau klien email Anda?.
Itu adalah gambaran cepat tentang penggunaan praktis S/MIME. Jika Anda ingin mendapatkan sertifikat email Anda sendiri, ada daftar penyedia di sini. Saya menemukan Comodo bekerja dengan baik (gratis untuk penggunaan non-komersial – buka ini di Firefox, bukan Chrome).
Di bagian 2, kita akan menjelajahi bagaimana menerapkan penandatanganan S/MIME dan enkripsi ke pesan yang Anda kirim melalui SparkPost.
Bacaan lebih lanjut
Microsoft memiliki artikel pengantar yang baik tentang S/MIME dalam dokumentasi mereka.
Untuk informasi lebih lanjut tentang kerentanan EFAIL dan bagaimana itu ditangani, lihat situs web resmi EFAIL. Penjelasan lain yang mudah diikuti tersedia di halaman wiki EFAIL dan di posting blog CipherMail EFAIL: Mana yang rentan, PGP, S/MIME atau klien email Anda?.
