Gesaan dan konteks
Syarikat ingin mengurangkan risiko penurunan taraf (downgrade) SMTP STARTTLS dan serangan orang di tengah (man-in-the-middle) dengan menerbitkan rekod DNSSEC dan TLSA untuk domain penghantarannya. Bukan semua penerima menyokong DANE, dan sijil diganti secara berkala. Reka bentuk penemuan MX, pengesahan TLSA, sandaran (fallback) keserasian, penggantian (rotation), pemantauan dan pengunduran (rollback) insiden.
Perkara yang diuji oleh penemu duga
- Memahami bahawa SMTP DANE bergantung pada DNSSEC, sasaran MX dan TLSA, bukan hanya pada pihak berkuasa sijil (CA).
- Membezakan DANE oportunistik, TLSA yang dikuatkuasakan, MTA-STS dan pelaporan TLS.
- Mereka bentuk penjanaan TLSA, TTL, penggantian sijil dan pengendalian kegagalan DNSSEC.
- Memasukkan kejayaan penghantaran, penurunan taraf, kegagalan pengesahan dan keserasian penerima dalam pelancaran kenari (canary).
Soalan untuk dijelaskan terlebih dahulu
- Adakah anda melindungi domain penghantar, domain penerima atau kedua-duanya? Adakah MTA penghantar mengesahkan rakan setara (peers)?
- Adakah rantaian DNSSEC, penyelesai (resolver) dan tingkah laku cache boleh dipercayai?
- Berapakah bahagian penerima yang menyokong DANE, MTA-STS atau hanya STARTTLS?
- Adakah sijil dikeluarkan oleh CA atau ditandatangani sendiri, dan apakah tempoh tetingkap penggantian dan pengunduran?
- Apabila berlaku kegagalan, bolehkah penghantaran ditangguhkan (queue), atau adakah ia mesti berundur ke teks biasa (plaintext)?
Rangka jawapan 30 saat
MTA penghantar menyelesaikan MX, mengesahkan TLSA melalui DNSSEC dan menyemak sijil atau kunci rakan setara menggunakan penggunaan, pemilih, jenis pemadanan dan data perkaitan TLSA. Kegagalan DNSSEC atau ketidakpadanan TLSA tidak boleh dianggap sebagai kejayaan STARTTLS biasa; dasar harus menangguhkan atau menolak penghantaran. Mulakan dalam mod pemerhatian, laksanakan kenari mengikut domain, gabungkan MTA-STS dengan laporan TLS, dan lakukan penggantian dengan rekod yang bertindih serta tetingkap pengunduran.
Jawapan terperinci langkah demi langkah
Langkah 1: Jejak laluan protokol
Penghantar memperoleh hos pengangkutan daripada rekod MX domain penerima dan merundingkan STARTTLS. DANE menggunakan rekod TLSA yang dilindungi DNSSEC untuk mengikat domain, port dan sijil atau kunci sasaran. Ia tidak menganggap nama MX sebagai nama sijil atau memintas jabat tangan TLS dan peraturan nama hos.
Langkah 2: Pilih semantik TLSA
Penggunaan sijil, pemilih dan jenis pemadanan TLSA menentukan apa yang dipadankan. Rekod boleh memadankan sijil penuh, SubjectPublicKeyInfo atau penghadaman (digest). Pilihan yang lebih longgar memudahkan penggantian; pilihan yang lebih ketat memberikan kawalan yang lebih kukuh. Rekod mesti mewakili rantaian penggunaan sebenar dan mengambil kira kunci sandaran daripada sekadar menyalin satu cap jari semasa.
Langkah 3: Reka bentuk DNSSEC dan TTL
Sahkan rantaian DNSSEC dari zon induk ke TLSA dan pantau tamat tempoh tandatangan, perubahan DS dan ralat resolusi. TTL mengawal penyebaran penggantian dan kelajuan pembatalan, jadi pertindihkan rekod untuk tetingkap yang diperlukan. Bezakan kegagalan DNSSEC, SERVFAIL dan NXDOMAIN daripada "tiada TLSA" untuk mengelakkan penurunan taraf palsu selepas kerosakan penyelesai atau cache.
Langkah 4: Bina dasar keserasian
Sahkan TLSA untuk destinasi yang berkemampuan DANE. Bagi yang lain, gunakan dasar domain untuk MTA-STS, STARTTLS biasa atau barisan gilir (queueing). Penguatkuasaan tidak boleh berundur ke teks biasa secara senyap. Masukkan sebab kegagalan, destinasi, status DNSSEC dan masa percubaan semula ke dalam barisan gilir dan laporan TLS dan bukannya satu ralat sambungan generik.
Langkah 5: Gantikan sijil dan kunci
Terbitkan rekod TLSA baharu dan lama, gunakan sijil atau kunci baharu, tunggu sehingga TTL dan tetingkap pemerhatian berlalu, kemudian alih keluar rekod lama. Sahkan paparan daripada beberapa penyelesai dan MTA pada setiap langkah. Untuk pemadanan digest, rekodkan alat, algoritma dan input. Penggantian yang gagal akan memulihkan kedua-dua rekod lama dan sijil lama.
Langkah 6: Kenari dan perhatikan
Mulakan dengan domain penerima dalaman atau berisiko rendah dalam mod pemerhatian, kemudian kuat kuasakan secara beransur-ansur. Pantau kejayaan penghantaran, pemadanan TLSA, kegagalan DNSSEC, ketidakpadanan sijil, umur barisan gilir dan penurunan taraf teks biasa. Kumpulkan dan padamkan maklumat sensitif (redact) laporan TLS; jangan hantar alamat penerima atau metadata mesej penuh kepada pihak ketiga.
Langkah 7: Latih insiden dan pemulihan
Latih tubi tandatangan DNSSEC yang tamat tempoh, penerbitan TLSA yang salah, penggantian sijil awal, perubahan MX, kegagalan penyelesai dan rakan setara bukan DANE. Bekukan penguatkuasaan, lanjutkan percubaan semula barisan gilir dan undurkan DNS atau sijil; nyahbekukan hanya selepas MTA bebas dan pelbagai penyelesai awam mengesahkan pemulihan.
Contoh jawapan berkualiti tinggi
Saya akan menjadikan MX, DNSSEC, TLSA dan SMTP TLS sebagai langkah berasingan yang boleh diperhatikan: selesaikan MX, sahkan DNSSEC, kemudian periksa sijil atau kunci rakan setara menggunakan penggunaan, pemilih dan jenis pemadanan TLSA. Kegagalan DNSSEC atau ketidakpadanan TLSA membawa kepada penolakan dasar domain atau penggilirian, bukan teks biasa secara senyap. Lancarkan dalam mod pemerhatian, lakukan penguatkuasaan kenari, dan gabungkan MTA-STS dengan laporan TLS. Terbitkan rekod TLSA yang bertindih sebelum sijil baharu, tunggu sehingga TTL tamat, kemudian alih keluar rekod lama. Kekalkan laluan pengunduran DNS dan sijil serta latih tubi tamat tempoh tandatangan, perubahan MX dan kegagalan penyelesai.
Kesilapan lazim
- Menganggap DANE hanya sebagai pemeriksaan CA atau pemeriksaan nama hos MX.
- Meneruskan dengan STARTTLS biasa atau teks biasa selepas pengesahan DNSSEC gagal.
- Mengalih keluar rekod TLSA lama sebelum menggunakan sijil pengganti.
- Menguji dengan hanya satu penyelesai dan penghantar serta mengabaikan penyebaran cache.
- Menyertakan alamat penerima dan metadata mesej penuh dalam laporan TLS.
Soalan susulan dan respons
Soalan susulan 1: Bagaimanakah DANE dan MTA-STS berbeza?
DANE bergantung pada DNSSEC dan TLSA serta sesuai untuk MTA yang mengesahkan DNSSEC. MTA-STS menerbitkan dasar melalui HTTPS dan bergantung pada sijil CA. Kedua-duanya boleh wujud bersama; pilih mengikut keupayaan rakan setara dan sempadan operasi dan bukannya menganggap satu sebagai sandaran senyap untuk yang lain.
Soalan susulan 2: Adakah TLSA memadankan kunci awam atau sijil?
Pemilih dan jenis pemadanan menentukannya. Kunci atau digest boleh mengurangkan kepekaan terhadap perubahan rantaian sijil, tetapi simpan input, algoritma dan rekod penggantian yang tepat untuk mengelakkan digest yang salah.
Soalan susulan 3: Bolehkah penghantaran berundur ke teks biasa selepas DNSSEC SERVFAIL?
Tidak apabila dasar domain memerlukan DANE. Tangguhkan atau tolak dan beri amaran. Hanya dasar keserasian yang dibenarkan secara eksplisit boleh memilih laluan lain, dan ia mesti merekodkan penurunan taraf tersebut.
Soalan susulan 4: Bagaimanakah anda mengundurkan penerbitan TLSA yang buruk?
Pulihkan TLSA dan sijil lama, tunggu DNS autoritatif, cache TTL dan pelbagai penyelesai rekursif menumpu (converge), kemudian lepaskan pembekuan barisan gilir. Simpan rekod yang tidak elok, domain yang terjejas dan masa pemulihan untuk audit.
Soalan susulan 5: Bagaimanakah anda membuktikan bahawa tiada penurunan taraf teks biasa?
Rekodkan rundingan TLS, status TLSA dan kiraan penurunan taraf bagi setiap domain destinasi dan sahkan secara berkala daripada MTA bebas. Anggap percubaan teks biasa sebagai amaran berkeutamaan tinggi dan selaraskan dengan laporan TLS serta log penghantaran.