Perintah dan konteks
Perusahaan ingin mengurangi risiko penurunan versi (downgrade) SMTP STARTTLS dan serangan man-in-the-middle dengan memublikasikan rekaman DNSSEC dan TLSA untuk domain pengirimnya. Tidak semua penerima mendukung DANE, dan sertifikat dirotasi secara berkala. Rancang penemuan MX, validasi TLSA, fallback kompatibilitas, rotasi, pemantauan, dan rollback insiden.
Hal yang diuji oleh pewawancara
- Memahami bahwa SMTP DANE bergantung pada DNSSEC, target MX, dan TLSA, bukan hanya pada certificate authority (CA).
- Membedakan antara DANE oportunistik, TLSA yang ditegakkan (enforced), MTA-STS, dan pelaporan TLS.
- Merancang pembuatan TLSA, TTL, rotasi sertifikat, dan penanganan kegagalan DNSSEC.
- Menyertakan keberhasilan pengiriman, downgrade, kegagalan validasi, dan kompatibilitas penerima dalam peluncuran canary.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah Anda melindungi domain pengirim, domain penerima, atau keduanya? Apakah MTA pengirim memvalidasi peer?
- Apakah rantai DNSSEC, resolver, dan perilaku cache dapat diandalkan?
- Berapa proporsi penerima yang mendukung DANE, MTA-STS, atau hanya STARTTLS?
- Apakah sertifikat diterbitkan oleh CA atau self-signed, dan berapa lama jendela rotasi serta rollback?
- Saat terjadi kegagalan, apakah pengiriman boleh ditunda (antrean), atau harus dialihkan kembali ke teks biasa (plaintext)?
Kerangka jawaban 30 detik
MTA pengirim me-resolve MX, memvalidasi TLSA melalui DNSSEC, dan memeriksa sertifikat atau kunci peer menggunakan penggunaan (usage), pemilih (selector), tipe pencocokan (matching type), dan data asosiasi TLSA. Kegagalan DNSSEC atau ketidakcocokan TLSA tidak boleh diperlakukan sebagai keberhasilan STARTTLS biasa; kebijakan harus menunda atau menolak pengiriman. Mulai dalam mode observasi, lakukan canary per domain, gabungkan MTA-STS dengan laporan TLS, dan lakukan rotasi dengan rekaman yang tumpang tindih (overlapping) serta jendela rollback.
Jawaban mendalam langkah demi langkah
Langkah 1: Telusuri jalur protokol
Pengirim memperoleh host transport dari rekaman MX domain penerima dan menegosiasikan STARTTLS. DANE menggunakan rekaman TLSA yang dilindungi DNSSEC untuk mengikat domain, port, serta sertifikat atau kunci target. DANE tidak memperlakukan nama MX sebagai nama sertifikat atau melewati handshake TLS dan aturan nama host.
Langkah 2: Pilih semantik TLSA
Penggunaan sertifikat, pemilih, dan tipe pencocokan TLSA menentukan apa yang dicocokkan. Rekaman dapat mencocokkan sertifikat lengkap, SubjectPublicKeyInfo, atau digest. Pilihan yang lebih longgar mempermudah rotasi; pilihan yang lebih ketat memberikan kontrol yang lebih kuat. Rekaman harus mewakili rantai penerapan yang sebenarnya dan memperhitungkan kunci cadangan daripada hanya menyalin satu sidik jari saat ini.
Langkah 3: Rancang DNSSEC dan TTL
Verifikasi rantai DNSSEC dari zona induk ke TLSA dan pantau kedaluwarsa tanda tangan, perubahan DS, serta kesalahan resolusi. TTL mengontrol propagasi rotasi dan kecepatan pencabutan, jadi tumpang tindihkan rekaman selama jendela waktu yang diperlukan. Bedakan kegagalan DNSSEC, SERVFAIL, dan NXDOMAIN dari "tidak ada TLSA" untuk menghindari downgrade palsu setelah terjadi gangguan pada resolver atau cache.
Langkah 4: Bangun kebijakan kompatibilitas
Validasi TLSA untuk tujuan yang mendukung DANE. Untuk tujuan lainnya, terapkan kebijakan domain untuk MTA-STS, STARTTLS biasa, atau antrean. Penegakan aturan tidak boleh dialihkan secara diam-diam ke plaintext. Masukkan alasan kegagalan, tujuan, status DNSSEC, dan waktu percobaan ulang ke dalam antrean dan laporan TLS, bukan hanya pesan kesalahan koneksi umum.
Langkah 5: Rotasi sertifikat dan kunci
Publikasikan rekaman TLSA baru dan lama, terapkan sertifikat atau kunci baru, tunggu hingga TTL dan jendela observasi selesai, lalu hapus rekaman lama. Verifikasi tampilan dari beberapa resolver dan MTA di setiap langkah. Untuk pencocokan digest, catat alat, algoritma, dan input yang digunakan. Rotasi yang gagal akan memulihkan rekaman lama dan sertifikat lama.
Langkah 6: Canary dan observasi
Mulai dengan domain penerima internal atau berisiko rendah dalam mode observasi, lalu terapkan penegakan secara bertahap. Pantau keberhasilan pengiriman, kecocokan TLSA, kegagalan DNSSEC, ketidakcocokan sertifikat, usia antrean, dan downgrade ke plaintext. Agregasikan dan sensor (redact) laporan TLS; jangan mengirim alamat penerima atau metadata pesan lengkap ke pihak ketiga.
Langkah 7: Latih penanganan insiden dan pemulihan
Lakukan simulasi tanda tangan DNSSEC kedaluwarsa, publikasi TLSA yang salah, rotasi sertifikat dini, perubahan MX, kegagalan resolver, dan peer non-DANE. Bekukan penegakan, perpanjang percobaan ulang antrean, dan lakukan rollback pada DNS atau sertifikat; buka pembekuan hanya setelah MTA independen dan beberapa resolver publik mengonfirmasi pemulihan.
Contoh jawaban berkualitas tinggi
Saya akan membuat MX, DNSSEC, TLSA, dan SMTP TLS sebagai langkah terpisah yang dapat diamati: resolve MX, validasi DNSSEC, lalu periksa sertifikat atau kunci peer menggunakan penggunaan, pemilih, dan tipe pencocokan TLSA. Kegagalan DNSSEC atau ketidakcocokan TLSA menghasilkan penolakan kebijakan domain atau antrean, tidak pernah dialihkan ke plaintext secara diam-diam. Terapkan dalam mode observasi, lakukan penegakan bertahap (canary), dan gabungkan MTA-STS dengan laporan TLS. Publikasikan rekaman TLSA yang tumpang tindih sebelum sertifikat baru, tunggu hingga masa TTL berlalu, lalu hapus rekaman lama. Pertahankan jalur rollback DNS dan sertifikat serta latih skenario kedaluwarsa tanda tangan, perubahan MX, dan kegagalan resolver.
Kesalahan umum
- Menganggap DANE hanya sebagai pemeriksaan CA atau pemeriksaan nama host MX.
- Melanjutkan dengan STARTTLS biasa atau plaintext setelah validasi DNSSEC gagal.
- Menghapus rekaman TLSA lama sebelum menerapkan sertifikat pengganti.
- Menguji hanya dengan satu resolver dan pengirim serta mengabaikan propagasi cache.
- Menyertakan alamat penerima dan metadata pesan lengkap dalam laporan TLS.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Apa perbedaan antara DANE dan MTA-STS?
DANE bergantung pada DNSSEC dan TLSA serta cocok untuk MTA yang memvalidasi DNSSEC. MTA-STS memublikasikan kebijakan melalui HTTPS dan bergantung pada sertifikat CA. Keduanya dapat berdampingan; pilih berdasarkan kemampuan peer dan batas operasional daripada memperlakukan salah satunya sebagai fallback diam-diam untuk yang lain.
Pertanyaan lanjutan 2: Apakah TLSA mencocokkan kunci publik atau sertifikat?
Pemilih dan tipe pencocokan yang menentukannya. Kunci atau digest dapat mengurangi sensitivitas terhadap perubahan rantai sertifikat, tetapi simpan input yang tepat, algoritma, dan rekaman rotasi untuk menghindari kesalahan digest.
Pertanyaan lanjutan 3: Bisakah pengiriman dialihkan kembali ke plaintext setelah DNSSEC SERVFAIL?
Tidak jika kebijakan domain mewajibkan DANE. Tunda atau tolak dan berikan peringatan. Hanya kebijakan kompatibilitas yang diizinkan secara eksplisit yang dapat memilih jalur lain, dan itu harus mencatat terjadinya downgrade.
Pertanyaan lanjutan 4: Bagaimana cara melakukan rollback pada publikasi TLSA yang salah?
Pulihkan TLSA dan sertifikat lama, tunggu hingga authoritative DNS, cache TTL, dan beberapa recursive resolver konvergen, lalu lepaskan pembekuan antrean. Simpan rekaman yang salah, domain yang terpengaruh, dan waktu pemulihan untuk audit.
Pertanyaan lanjutan 5: Bagaimana Anda membuktikan bahwa tidak ada downgrade ke plaintext?
Catat negosiasi TLS, status TLSA, dan jumlah downgrade per domain tujuan, lalu verifikasi secara berkala dari MTA independen. Perlakukan upaya penggunaan plaintext sebagai peringatan berprioritas tinggi dan rekonsiliasikan dengan laporan TLS serta log pengiriman.