Temukan modifikasinya sebelum menyalahkan gateway
Gerbang keamanan dapat secara sah memeriksa atau mengubah email sambil mempersulit proses hilir DKIM verifikasi. Penulisan ulang URL, penggantian lampiran, dan peringatan isi adalah contoh yang mungkin terjadi, namun kehadiran gateway saja tidak membuktikan apa pun tentang kegagalan tanda tangan. Tetapkan representasi mana yang memasuki gateway, yang meninggalkannya, dan di mana otentikasi dievaluasi.
Tidak ada akun gateway atau aliran pesan yang diakses untuk artikel ini. Gerbang bukti asli: Pesan mentah asli dan yang dimodifikasi, penempatan penanda tangan, dan tes verifikasi sebelum dan sesudah. Barang-barang ini masih belum dikumpulkan. Kasus yang dikerjakan adalah fiksi. Setiap perubahan operasional harus mempertahankan kontrol keamanan yang dimaksudkan dan mengikuti proses yang disetujui pemilik.
Inventarisasi urutan pemrosesan yang tepat
Gambarkan urutan mulai dari penerimaan pesan hingga autentikasi, pemeriksaan ancaman, modifikasi konten, penandatanganan, dan pengiriman selanjutnya. Suatu layanan dapat menggabungkan fungsi-fungsi ini, dan beberapa gateway mungkin muncul pada satu rute. Catat versi dan perilaku yang diaktifkan hanya jika didukung oleh konfigurasi sebenarnya. Jangan berasumsi bahwa suatu produk selalu melakukan verifikasi sebelum menulis ulang, atau bahwa konektor keluarnya selalu memberi tanda.
RFC 7960 menjelaskan filter batas yang menghapus konten berbahaya, menandai dugaan spam, atau mengubah URL. Hal ini juga menjelaskan mengapa mengevaluasi autentikasi setelah modifikasi filter dapat memberikan hasil yang berbeda. Ini adalah kemungkinan arsitektural, bukan keputusan tentang penyewa tertentu. Jejak pesan dan salinan yang disimpan diperlukan untuk menghubungkan mekanisme yang terdokumentasi dengan suatu insiden. RFC 7960 bagian 3.2.5
Tentukan apa yang tercakup dalam tanda tangan yang gagal
Untuk masing-masing DKIM-Signature, pertahankan domain penandatanganan d=, pemilih s=, kanonikalisasi c=, header list h= and any l= body-length value. The hash tubuh dihitung berdasarkan masukan isi kanonikalisasi yang dipilih; tanda tangan juga mencakup contoh header tertentu. “Gerbang mengubah header” tidak lengkap tanpa mengetahui apakah instance tersebut dipilih dan apakah kanonikalisasi mempertahankan perbedaannya. RFC 6376 bagian 3.4–3.5 dan 5.4
Kanonikalisasi yang santai menoleransi perubahan spasi dan format header tertentu. Itu tidak memperlakukan pengeditan HTML sewenang-wenang, penggantian URL, atau perubahan lampiran sebagai konten yang setara. Sebaliknya, kolom tambahan di luar cakupan yang dipilih tidak perlu membuat tanda tangan yang sudah ada menjadi tidak valid. Duplikasi dan penandatanganan header dapat mempersulit penilaian tersebut, jadi bandingkan contoh yang dipilih daripada hanya daftar nama bidang unik. RFC 6376 bagian 3.4 dan 5.4
Bandingkan pesan mentah tanpa mengubah bukti
Gunakan file pesan mentah yang tidak diubah dari titik pengambilan yang disetujui. Tangkapan layar yang dirender dapat menyembunyikan batas MIME , pengkodean perubahan, dan header terlipat. Menyimpan ulang pesan melalui editor dapat mengubah akhir baris atau serialisasi, jadi simpanlah yang asli dan lakukan analisis pada salinannya. Catat waktu pengambilan, posisi rute, dan hash file untuk menghubungkan setiap sampel ke langkah yang diklaim.
Tanda tangan yang gagal kemudian tidak menetapkan bahwa tanda tangan tersebut valid sebelum gateway. RFC 6376 memperingatkan bahwa verifikator secara umum tidak dapat menyimpulkan validitas sebelumnya dari tanda tangan yang tidak valid. Oleh karena itu, pengujian yang diusulkan mencakup verifikasi masukan dan keluaran yang disimpan, dengan konteks kunci dan pemverifikasi yang relevan dipertahankan. Jika tidak, kesalahan penandatanganan yang sudah ada sebelumnya dapat disalahartikan ke gateway. RFC 6376 bagian 4.2
Bekerja melalui penggantian URL fiktif
Misalkan tanda tangan domain penulis fiktif memverifikasi pesan masukan mentah dan menutupi seluruh isi pesan. Gateway kemudian mengganti URL di bagian MIME HTML dengan URL perlindungan ancaman. Output yang sesuai berisi byte tubuh yang dikanonikalisasi berbeda, dan upaya verifikasi melaporkan ketidakcocokan hash tubuh. Asumsi ini membentuk hasil tes ilustratif; tidak ada tes seperti itu yang dilakukan di sini.
Perbandingan tersebut mendukung kesimpulan sempit bahwa penggantian yang diamati memengaruhi badan tertutup tanda tangan ini. Hal ini tidak berarti bahwa setiap tindakan gateway merusak setiap tanda tangan atau perlindungan harus dimatikan. Tanda tangan tambahan dari gateway.example dapat mengautentikasi penanganan domain tersebut terhadap pesan yang diubah, namun tidak merekonstruksi tanda tangan penulis asli atau secara otomatis menyelaraskan dengan domain penulis yang tidak terkait. RFC 6376 bagian 3.4 dan 5.1 RFC 9989 bagian 5.3
Jaga agar hasil masuk dan verifikasi downstream tetap berbeda
Suatu organisasi mungkin mengandalkan autentikasi yang dilakukan pada ingress tepercaya sebelum melakukan transformasi keamanan internal. Pertahankan identitas penilai dan batas kepercayaan di balik hasil tersebut. Penerima hilir yang mengevaluasi byte yang dimodifikasi mungkin mendapatkan hasil DKIM yang berbeda dengan benar. Menyalin sebuah Authentication-Results bidang menjadi sebuah pesan tidak dengan sendirinya membuat bidang tersebut dapat dipercaya di luar batas yang menghasilkannya. RFC 8601 bagian 5 dan 7
ARC dapat melakukan penilaian sebelumnya melalui penangan yang berpartisipasi, namun validasi rantai dan kepercayaan pada penangan tersebut tetap menjadi pertanyaan yang berbeda. RFC 8617 tidak menjadikan ARC sebagai mekanisme pemulihan tanda tangan DKIM yang lama. Kategori terbitannya adalah Eksperimental; proposal yang telah ditinjau untuk memindahkan ARC ke Historic tetap merupakan draf aktif. Jangan berjanji bahwa mengaktifkan ARC membuat setiap penerima hilir menerima email yang dimodifikasi gateway. RFC 8617 bagian 5.2 dan 9.3 Status usulan IETF
Tempatkan penandatanganan yang sah setelah perubahan yang dimaksudkan
Untuk email keluar yang dibuat di bawah domain yang dikontrol organisasi, desain yang didukung dapat menempatkan penandatangan resmi setelah perubahan konten akhir yang sah. Verifikasi bahwa langkah selanjutnya tidak mengubah konten yang tercakup lagi. Sebuah gateway tidak dapat secara sah masuk sebagai domain penulis eksternal hanya karena gateway tersebut menyampaikan pesan penulis tersebut; otorisasi domain dan penyimpanan kunci yang relevan harus ada. RFC 6376 bagian 5.1
Paket peninjauan harus menyatakan kontrol mana yang tetap aktif, perintah pemrosesan mana yang diusulkan, dan bagaimana verifikasi sebelum dan sesudah akan diulang. Jangan gunakan pengurangan cakupan tubuh atau bypass otentikasi menyeluruh hanya untuk menghasilkan indikator hijau. Pengujian resmi yang berhasil hanya akan mendukung rute sampel dan formulir pesannya. Pasangan mentah asli, penempatan penandatangan sebenarnya, dan hasil verifikasi terkontrol masih belum ada dalam draf ini.