Temu Duga Backend: Bagaimanakah Anda Mendiagnosis Kegagalan SMTP TLS dengan TLS-RPT?

Soalan dan senario

Anda mengendalikan domain penerima berbilang MX merentasi beberapa penyedia. Selepas mendayakan MTA-STS, sesetengah penghantar melaporkan kegagalan jabat tangan TLS. Terangkan cara anda menggunakan SMTP TLS Reporting (TLS-RPT) untuk memerhati, mendiagnosis dan melancarkan pembaikan secara selamat.

Perkara yang diuji oleh penemu duga

• Membezakan telemetri (TLS-RPT) daripada penguatkuasaan (MTA-STS dan DANE).
• Menghubungkan DNS, sijil, STARTTLS, fail dasar HTTPS dan laluan MX sandaran.
• Menggunakan pelancaran berperingkat, metrik, amaran dan unduran (rollback) untuk melindungi kebolehhantaran.

Soalan penjelasan sebelum menjawab

Sahkan set MX domain, sama ada MTA-STS atau DANE didayakan, destinasi TLS-RPT, tetingkap laporan, dan sama ada kegagalan bersifat menyeluruh atau tertumpu pada satu penghantar atau MX sandaran. Jelaskan sama ada matlamatnya adalah untuk mengesan penurunan taraf kepada teks biasa (plaintext), menerangkan kegagalan penghantaran, atau mengesahkan pelancaran penguatkuasaan.

Rangka jawapan 30 saat

TLS-RPT, yang ditakrifkan oleh RFC 8460, ialah telemetri; ia tidak menguatkuasakan penyulitan. Saya akan menerbitkan rekod TXT _smtp._tls, mengumpul laporan agregat dan mengumpulkan kegagalan mengikut dasar, penghantar, MX dan sebab. Kemudian saya akan mengesahkan STARTTLS, identiti dan rantaian sijil, DNS serta fail HTTPS MTA-STS untuk setiap MX. Selepas membetulkan isu, saya akan memerhati dalam mod testing sebelum penguatkuasaan (enforce) dan mengekalkan laluan unduran yang telah diuji.

Jawapan mendalam langkah demi langkah

1. Terbitkan rekod seperti v=TLSRPTv1; rua=mailto:tls-reports@example.org; sahkan destinasi serta periksa penghuraian (parsing), pengekalan dan redaksi.
2. Huraikan agregat JSON RFC 8460 untuk dasar, MTA penghantar, MX, kejayaan dan sebab kegagalan. Kelompokkan mengikut masa, penyedia dan MX sandaran dan bukannya bergantung pada satu nombor kadar kegagalan.
3. Bagi setiap MX, sahkan DNS, port 25, STARTTLS, rantaian sijil dan nama. Bandingkan pemerhatian penghantar dengan log mel dan prob SMTP TLS yang jelas.
4. Untuk MTA-STS, periksa _mta-sts, fail HTTPS /.well-known/mta-sts.txt, modnya, corak MX dan caching. Untuk DANE, periksa pengesahan DNSSEC dan penjajaran TLSA dengan sijil.
5. Uji setiap MX, rekaman lapuk dan laluan failover dalam mod testing sebelum beralih ke enforce. Berikan amaran sekiranya berlaku peningkatan kadar kegagalan atau pada laluan/penyedia kritikal.
6. Uji semula dengan matriks yang sama selepas membetulkan sijil, fail dasar, DNSSEC atau konfigurasi penyedia. Jika penghantaran terjejas, turunkan mod MTA-STS atau alih keluar entri dasar yang bermasalah sambil mengekalkan pengumpulan TLS-RPT.

dig TXT _smtp._tls.example.org
dig TXT _mta-sts.example.org
curl https://mta-sts.example.org/.well-known/mta-sts.txt
openssl s_client -starttls smtp -connect mx1.example.org:25 -servername mx1.example.org

Contoh jawapan berkualiti tinggi

Saya menganggap TLS-RPT sebagai telemetri, bukan sebagai suis penyulitan. Mula-mula saya menerbitkan _smtp._tls dan menghantar laporan ke destinasi yang dikawal, kemudian membina garis dasar mengikut penghantar, MX sasaran, dasar dan sebab kegagalan. Bagi setiap laluan yang dilaporkan, saya memeriksa STARTTLS, rantaian dan nama sijil, TXT dan dasar HTTPS MTA-STS, atau DNSSEC/TLSA DANE; saya turut menyertakan MX sandaran dan TTL lapuk. Selepas pemulihan, saya kekal dalam mod testing sepanjang tetingkap laporan penuh dan ujian failover sebelum menetapkan kepada enforce. Jika penghantaran gagal, saya mengundurkan (rollback) mod dasar sambil mengekalkan laporan, dan bukannya menerima teks biasa secara senyap. Ini membahagikan pemerhatian, pembaikan dan penguatkuasaan kepada peringkat yang boleh diundur.

Kesilapan biasa

• Menganggap TLS-RPT sebagai penguatkuasaan TLS dan bukannya pelaporan.
• Hanya memeriksa MX utama dan terlepas pandang laluan sandaran, DNS lapuk atau laluan khusus penyedia.
• Memeriksa tarikh luput sijil tetapi tidak memeriksa SAN, rantaian, TLSA atau corak mx pada fail dasar.
• Beralih ke enforce tanpa tetingkap laporan yang lengkap, ambang batas dan rancangan unduran.
• Mentafsir ketiadaan laporan sebagai tiada kegagalan tanpa mengesahkan liputan penghantar dan kebenaran titik akhir (endpoint).

Soalan susulan dan respons

Apakah sempadan antara TLS-RPT dan MTA-STS?

TLS-RPT mengagregatkan bukti tentang hasil rundingan. MTA-STS menggunakan dasar HTTPS untuk mewajibkan penghantar mengesahkan TLS. Kedua-duanya bekerjasama: pelaporan mengesahkan pelancaran penguatkuasaan.

Laporan menyatakan certificate-mismatch. Apakah yang anda periksa dahulu?

Hasilkan semula jabat tangan terhadap MX yang dilaporkan, periksa SAN, SNI, rantaian dan DNS, kemudian periksa sama ada pengimbang beban (load balancer) atau nod sandaran masih menggunakan sijil lama.

Mengapakah DANE memerlukan perhatian khusus terhadap DNSSEC?

Kepercayaan TLSA bergantung pada pengesahan DNSSEC. Putaran sijil mesti mengemas kini TLSA secara atomik; jika tidak, penghantar yang menyokong DANE boleh menolak sambungan dan melaporkan kegagalan.

Bagaimanakah anda membuat unduran (rollback) selepas penguatkuasaan?

Simpan DNS dan fail dasar yang mempunyai versi, turunkan MTA-STS daripada enforce kepada testing atau alih keluar entri yang bermasalah, sahkan bahawa penghantaran dan laporan telah pulih, kemudian baiki punca utama sementara TLS-RPT terus mengumpul data.