[ DKIM ]

Selidiki kegagalan DKIM yang melibatkan akhiran baris

Pertahankan pesan mentah dan bedakan normalisasi transportasi dari perubahan spasi yang diizinkan oleh kanonikalisasi.

Oleh tim peneliti EmailAuth

[Poin-poin penting]

  • Normalisasikan pemisah jalur lokal sebelum menandatangani formulir yang dikirimkan.
  • Bedakan perubahan transportasi dari normalisasi alat ekspor.
  • Mencocokkan hash isi saja tidak menghasilkan tanda tangan DKIM yang valid.
Di halaman ini

Masalah akhir baris adalah masalah tingkat byte. Menyalin pesan ke editor, melihat baris yang sama dan menyimpulkan bahwa tidak ada perubahan bukanlah hal yang dapat diandalkan DKIM penyelidikan. Pertahankan representasi asli dan identifikasi apakah konversi terjadi sebelum penandatanganan, saat transit, atau hanya selama pengumpulan bukti.

Tetapkan bentuk yang diharapkan

Surat internet menggunakan pemisah baris CRLF. RFC 6376 §5.3 mengharuskan penandatangan untuk mengubah konvensi CR atau LF lokal menjadi urutan CRLF standar SMTP sebelum penandatanganan. Konversi harus diterapkan pada pesan yang dikirimkan, bukan hanya pada salinan pribadi yang diteruskan ke algoritma penandatanganan. Menandatangani satu representasi dan mengirimkan representasi lainnya mengundang ketidaksepakatan dalam verifikasi.

kanonikalisasi memiliki aturan yang lebih sempit daripada normalisasi teks umum. Kanonikalisasi tubuh sederhana mengabaikan baris kosong yang tertinggal dan menyediakan CRLF akhir yang diperlukan. Kanonikalisasi tubuh yang santai juga menghapus spasi di akhir baris dan mengompresi rangkaian spasi atau tab dalam satu baris. Biasanya tidak menghapus jeda baris yang berarti atau menggabungkan teks yang dibungkus. Algoritme header dan body dapat berbeda, jadi bacalah kedua bagian c daripada mengasumsikan mode tunggal.

Lindungi buktinya terlebih dahulu

Kumpulkan file pesan mentah dari penandatangan dan penerima menggunakan metode transformasi yang Anda pahami. Simpan file asli dan hash yang hanya dapat dibaca dari file tersebut. Dalam copy pekerjaan, periksa jumlah CRLF, bare LF, dan bare CR menggunakan alat yang peka terhadap byte. Tampilan penampil teks saja tidak cukup: banyak pemirsa yang merender setiap formulir sebagai jeda baris.

Tanyakan bagaimana sampel diperoleh. Pengaturan arsip, pipa shell, atau kontrol sumber dapat menormalkan akhir setelah pengiriman. Perbedaan dalam file yang diekspor tidak menunjukkan bahwa pesan SMTP itu sendiri berubah. Jika memungkinkan, bandingkan hasil tangkapan independen pada batas wilayah yang sama dan pertahankan prosedur ekspor dengan bukti yang ada.

Gunakan kotak kecil yang terkontrol

Masukan ilustrasi: suatu benda terdiri dari alfa, CRLF, beta, dan CRLF terakhir. Menambahkan baris kosong khusus CRLF di bagian akhir akan dinormalisasi oleh algoritma isi standar. Mengganti jeda baris antara alfa dan beta dengan spasi akan mengubah konten dan bukan operasi yang sama. Menambahkan spasi di akhir garis alfa berbeda pada kanonikalisasi isi sederhana tetapi dinormalisasi dengan kanonikalisasi isi santai.

Contoh-contoh ini menjelaskan aturannya; ini bukan pengganti untuk memverifikasi tanda tangan yang lengkap. Sah hash tubuh hanyalah salah satu bagian dari verifikasi DKIM . Pemilihan header, pengambilan kunci publik dan tanda tangan kriptografi juga harus berhasil.

Temukan dan perbaiki tahap yang bertanggung jawab

Jika penandatangan menerima data lokal khusus LF, periksa tahap serialisasi sebelum penandatanganan. Jika keluaran penandatangan benar tetapi tangkapan mentah selanjutnya berbeda, selidiki perilaku konversi atau pembangunan kembali hop tersebut. Jika hanya bukti yang Anda ekspor saja yang berbeda, perbaiki metode pengambilan daripada mengubah DNS atau kunci produksi.

Buat perubahan dengan cakupan sempit yang memastikan penanda tangan dan pesan yang dikirimkan menggunakan representasi normal yang sama. Jangan membuat pemverifikasi khusus yang menerima transformasi garis sewenang-wenang agar sampel lolos. Verifikator tersebut tidak lagi menguji aturan DKIM yang telah diterbitkan.

Verifikasi lebih dari satu pesan

Setelah perubahan, kirim rangkaian kecil yang mencakup teks biasa, baris tambahan kosong, HTML, dan lampiran. Catat kanonikalisasi yang dipilih, hash file mentah yang dikumpulkan, dan hasil verifikasi penerima tepercaya. Pertahankan representasi keluaran yang diharapkan sebagai perlengkapan regresi. Resolusi yang berguna mengidentifikasi konversi yang bertanggung jawab dan menunjukkan bahwa pesan baru sampai ke penerima dalam bentuk yang diinginkan.

Pisahkan jumlah byte dari kesimpulan

Untuk bodi sintetis alfa<CRLF>beta<CRLF>, badan bentuk jaringan terdiri dari 13 oktet: lima huruf, dua oktet pemisah, empat huruf, dan dua oktet pemisah akhir. Ekspor LF saja dari garis terlihat yang sama adalah 11 oktet. Perbedaan jumlah tersebut merupakan alasan untuk menyelidiki pengumpulan atau serialisasi, bukan bukti bahwa surat yang dikirimkan rusak. Simpan file asli dan metode pengumpulannya, lalu bandingkan dengan tangkapan tepercaya pada batas yang relevan. Label CRLF dalam tanda kurung mewakili byte, bukan teks literal.

[ Membawa pergi ]

Normalisasikan pemisah jalur lokal sebelum menandatangani formulir yang dikirimkan. Bedakan perubahan transportasi dari normalisasi alat ekspor. Mencocokkan hash isi saja tidak menghasilkan tanda tangan DKIM yang valid.

[ Berdasarkan peran ]

Apa artinya ini bagi Anda

Pilih peran Anda untuk langkah praktis selanjutnya.

Admin TI / Surat

Pertahankan oktet

Tentukan apakah perubahan terjadi pada transportasi atau ekspor.

Langkah selanjutnya

  1. Hash file asli.
  2. Periksa normalisasi sebelum penandatanganan.

CISO / Detik

Jangan melemahkan verifikasi

Menerima transformasi sewenang-wenang menyembunyikan perubahan integritas.

Langkah selanjutnya

  1. Pertahankan verifikasi berbasis standar.
  2. Tinjau retensi pengambilan.

Pendiri / Non-teknis

Mintalah perbaikan yang dapat direproduksi

Tangkapan layar atau sampel yang diedit bukan merupakan bukti bahwa rute pengiriman telah diperbaiki.

Langkah selanjutnya

  1. Minta tes pengiriman baru.
  2. Jauhkan data pelanggan dari perlengkapan.

[ FAQ ]

Pertanyaan yang sering diajukan

Apa itu CRLF?

Ini adalah urutan pengangkutan-pengembalian dan pengumpanan baris dua byte yang digunakan untuk pemisahan jalur surat Internet.

RFC 2045 §2.1

Apakah ekspor hanya LF merupakan bukti pengiriman yang rusak?

Tidak. Alat ekspor mungkin telah menormalkan file setelah pengiriman. Periksa metode penangkapan.

Apakah mode santai mengabaikan semua baris baru?

Tidak. Ini mempertahankan struktur garis yang bermakna sambil menerapkan aturan spasi putih dan garis kosong tambahan yang ditentukan.

RFC 6376 §3.4.4

Apakah baris ekstra kosong di akhir selalu merusak DKIM ?

Algoritme badan standar mengabaikan garis kosong yang tertinggal. Perubahan lainnya masih memerlukan evaluasi tersendiri.

RFC 6376 §3.4.3 RFC 6376 §3.4.4

Apakah kanonikalisasi header dan isi identik?

Tidak. Tag c dapat memilih algoritme berbeda untuk header dan isi, dan aturannya berbeda.

RFC 6376 §3.5

Haruskah kita memutar kuncinya terlebih dahulu?

Bukan karena ketidakcocokan representasi yang ditunjukkan. Perbaiki batas serialisasi; kunci baru tidak dapat mengembalikan byte yang diubah.

Apakah pencocokan bh cukup untuk membuktikan DKIM lolos?

Tidak. Tanda tangan header dan pemeriksaan verifikasi lainnya juga harus berhasil.

RFC 6376 §6.1.3

Apa yang harus dimuat dalam perlengkapan regresi?

Masukan mentah yang diketahui, keluaran normal yang diharapkan, pilihan kanonikalisasi, dan hasil verifikasi tepercaya untuk pesan pengujian baru.

[ Sumber ]

Sumber

  1. RFC 6376

    Bagian §1 · §3.4 · §3.4.1 · §3.4.2 · §3.4.3 · §3.4.4 · §3.5 · §5.3 · §6.1.3

  2. RFC 2045

    Bagian §2.1

  3. RFC 8601

    Bagian §1.2

[ Glosarium ]

Glosarium

CRLF
Pasangan carriage-return dan line-feed, dua oktet yang digunakan untuk pemisahan jalur surat Internet.

RFC 2045 §2.1

kanonikalisasi
Persiapan header atau isi yang ditentukan sebelum hashing dan verifikasi DKIM .

RFC 6376 §3.4

Hash tubuh (bh)
Hash yang dikodekan dari isi yang dikanonikalisasi dengan batas panjang apa pun yang berlaku.

RFC 6376 §3.5

Bukti pesan mentah
Pesan serial yang dikumpulkan yang metode penangkapan dan riwayat pelestariannya harus dipertahankan.

Asal perusahaan

Mengapa lembaga keuangan dan pemerintah terkemuka menghentikan dasbor keamanan email mereka.

Platform autentikasi email tradisional menjual dasbor kepada Anda dan meminta teknisi Anda melakukan pekerjaannya. Di lingkungan berisiko tinggi, pengawasan manual berarti penegakan yang tertunda, penyimpangan konfigurasi, dan domain bayangan yang tidak dipantau.

EmailAuth adalah platform asal email agen. Agen kami menegakkan p=reject, jaga agar pengirim pihak ketiga tetap selaras dan pindahkan domain Anda ke kapasitas penuh RFC 9989 kepatuhan, standar DMARC baru, dengan kemampuan audit yang dapat dilakukan secara langsung oleh manusia.

Pemerintah Perusahaan besar Lembaga keuangan tingkat 1

SaaS · Penyewaan khusus · On-prem dengan celah udara · Enkripsi BYOK

Basis Pengetahuan