Prompt dan skenario
Anda sedang merancang protokol lapisan aplikasi baru di atas TCP. Tim produk menginginkan kompatibilitas TLS 1.2 saat peluncuran, sedangkan tim keamanan hanya menginginkan TLS 1.3. Dengan menggunakan RFC 9852, jelaskan versi default, perilaku kegagalan handshake, migrasi klien lama, kesiapan pasca-kuantum (PQC), dan mengapa kesimpulan yang sama tidak dapat diterapkan secara langsung pada DTLS.
Hal yang dinilai oleh pewawancara
- Apakah Anda membedakan antara protokol baru yang mewajibkan TLS 1.3 dengan migrasi layanan yang sudah ada.
- Apakah Anda dapat menjelaskan peningkatan TLS 1.3 terkait kriptografi yang lemah, negosiasi ulang (renegotiation), privasi handshake, dan kompleksitas konfigurasi, alih-alih sekadar menghafal nomor versi.
- Apakah negosiasi versi, kapabilitas klien, observabilitas, rollback, dan biaya kompatibilitas dapat diubah menjadi rencana rilis yang dapat dieksekusi.
- Apakah Anda memahami bahwa RFC 9852 menargetkan TLS, bukan DTLS, dan dapat mengidentifikasi aturan integrasi yang berbeda seperti pada QUIC.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Konfirmasikan apakah protokol menggunakan TLS atau DTLS, apakah UDP diperlukan, frekuensi pembaruan klien, keberadaan perangkat embedded, dan apakah model ancaman mencakup observasi pasif, downgrade, dan analisis lalu lintas. Tanyakan tentang proksi, middlebox, dan siklus pembaruan offline yang panjang. Untuk protokol TLS yang benar-benar baru, RFC 9852 adalah titik awal normatif; untuk protokol yang sudah ada, migrasi dan kompatibilitas memerlukan analisis terpisah.
Kerangka jawaban 30 detik
Untuk protokol baru yang menggunakan TLS, saya akan menetapkan TLS 1.3 sebagai batas minimum dan default, serta menghentikan koneksi jika peer tidak dapat menegosiasikannya. RFC 9852 mengizinkan TLS 1.2 sebagai opsi tambahan non-default jika realitas penerapan mengharuskannya, tetapi spesifikasi baru harus memprioritaskan TLS 1.3. Migrasi mencakup inventarisasi kapabilitas, pembaruan klien secara bertahap, kegagalan handshake yang dapat didiagnosis, dan tanggal penghentian (sunset date); pertukaran kunci tetap dapat diperluas untuk PQC. Kesimpulan ini tidak berlaku langsung untuk DTLS karena RFC 9852 menyatakan bahwa DTLS 1.3 belum diterapkan secara luas.
Pembahasan mendalam langkah demi langkah
1. Batasi spesifikasi
RFC 9852 mencakup protokol-protokol baru yang menggunakan TLS: protokol tersebut harus mengasumsikan bahwa TLS 1.3 tersedia dan mewajibkannya. Ini memperbarui RFC 9325 tanpa mengubah persyaratan DTLS. Protokol yang menggunakan QUIC mengikuti integrasi TLS 1.3 milik QUIC daripada menyalin handshake lapisan aplikasi TCP.
2. Jelaskan peningkatan keamanan TLS 1.3
TLS 1.3 menghapus beberapa jalur kriptografi yang lemah dan pilihan negosiasi yang rumit, sekaligus mengenkripsi lebih banyak konten handshake. TLS 1.2 tidak serta-merta tidak aman, tetapi penerapan yang aman memerlukan konfigurasi tambahan untuk renegotiation, pertukaran kunci lama, dan cipher suite yang lemah. Mewajibkan TLS 1.3 menjadikan baseline ini bagian integral dari protokol, bukan sekadar panduan konfigurasi penerapan manual.
3. Tentukan negosiasi dan kegagalan
Tulis versi TLS minimum ke dalam protokol dan wajibkan klien untuk menawarkan TLS 1.3. Server memilih versi tertinggi yang didukung oleh kedua belah pihak; jika protokol baru hanya mengizinkan TLS 1.3, ketiadaan versi yang sama akan menghentikan koneksi dengan kategori kesalahan yang dapat diamati (observable). Protokol tidak boleh melakukan fallback secara diam-diam ke plaintext atau TLS 1.2. Log harus mencatat versi, kelas kesalahan, dan ringkasan kapabilitas peer, tanpa pernah mencatat kunci atau payload.
4. Tangani kompatibilitas praktis TLS 1.2
Jika perangkat keras atau siklus pembaruan pelanggan membuat penghentian langsung menjadi mustahil, definisikan TLS 1.2 sebagai opsi tambahan non-default dengan cakupan, tanggal sunset, dan pemilik risiko (risk owner) yang jelas. Default, contoh, dan pengujian harus menggunakan TLS 1.3. Jalur TLS 1.2 harus memiliki pemantauan terpisah, batas laju (rate limit), pelarangan cipher suite yang lemah, dan tombol penonaktifan; kompatibilitas tidak boleh menjadi default permanen.
5. Rencanakan migrasi klien
Inventarisasi versi klien, kapabilitas pustaka (library), dan penyebab kegagalan, lalu lakukan peluncuran bertahap: klien baru mengimplementasikan TLS 1.3, klien lama memperbarui pustaka dan konfigurasi, server memantau pangsa negosiasi, dan TLS 1.2 akhirnya dinonaktifkan. Petakan kegagalan handshake ke panduan pembaruan yang dapat ditindaklanjuti, serta siapkan prosedur peluncuran, rollback, dan dukungan alih-alih menyembunyikan perangkat long-tail di balik cutover massal satu kali.
6. Sertakan PQC dan operasional
RFC 9852 mengidentifikasi TLS 1.3 sebagai dasar untuk standardisasi pasca-kuantum (PQC) yang sedang berlangsung. Hindari melakukan hard-code pada satu algoritma pertukaran kunci; berikan ruang untuk pembaruan dan skema hibrida. Pantau distribusi versi, latensi handshake, kegagalan, upaya downgrade, dan kesalahan sertifikat. Pastikan pustaka tetap mutakhir dan jalankan pengujian interoperabilitas untuk mengungkap perbedaan implementasi.
Contoh jawaban berkualitas tinggi
Pertama-tama, saya akan mengonfirmasi bahwa ini adalah protokol lapisan aplikasi TCP yang baru, bukan migrasi protokol yang sudah ada. Untuk protokol TLS baru, RFC 9852 menjadikan TLS 1.3 sebagai batas minimum dan default; kegagalan dalam menegosiasikannya akan menghentikan koneksi. TLS 1.2 dapat tetap menjadi opsi tambahan non-default karena kendala penerapan, tetapi spesifikasi, contoh, dan matriks pengujian harus tetap mengutamakan TLS 1.3 dengan risk owner, pemantauan, dan tanggal penonaktifan. TLS 1.3 menghapus jalur yang lemah, mengurangi beban konfigurasi, dan mengenkripsi lebih banyak konten handshake. Migrasi dimulai dengan inventarisasi kapabilitas klien, pembaruan pustaka dan perangkat embedded, lalu secara bertahap menonaktifkan TLS 1.2. Pesan kesalahan harus menampilkan kategori versi yang dapat ditindaklanjuti tanpa membeberkan kunci atau payload. Pertukaran kunci tetap dapat diperluas untuk PQC, dan tata kelola menggunakan metrik pangsa versi, tingkat kegagalan, latensi, serta pengujian interoperabilitas. RFC 9852 secara eksplisit mengecualikan DTLS, sehingga perancangan ulang berbasis UDP memerlukan penilaian versi dan penerapan DTLS yang terpisah.
Kesalahan umum
- Menyebut TLS 1.2 secara universal tidak aman dan mengabaikan perbedaan dalam RFC 9852 antara protokol baru dan penerapan yang sudah ada.
- Melakukan downgrade secara diam-diam ke TLS 1.2, plaintext, atau enkripsi kustom.
- Menerapkan kesimpulan TLS secara langsung ke DTLS atau mengabaikan integrasi TLS pada QUIC.
- Hanya mengatakan "tingkatkan versi klien" tanpa inventarisasi kapabilitas, kegagalan yang dapat diobservasi, peluncuran bertahap, dan tanggal sunset.
- Melakukan hard-code pada algoritma pertukaran kunci sehingga menghambat evolusi PQC atau pustaka di masa mendatang.
Pertanyaan lanjutan dan jawabannya
Mengapa TLS 1.2 hanya boleh menjadi non-default?
RFC 9852 menyoroti penerapan TLS 1.3 yang sudah luas serta peningkatannya terhadap keamanan dan privasi dibandingkan TLS 1.2. Mempertahankan TLS 1.2 hanya berfungsi untuk memenuhi kendala penerapan yang spesifik; hal ini tidak boleh membuat baseline protokol baru bergantung pada apakah setiap pengembang menonaktifkan jalur lama dengan benar.
Kapan TLS 1.2 dapat dihapus sepenuhnya?
Hapus setelah versi klien, dukungan pustaka, dan pangsa negosiasi di wilayah-wilayah penting telah mencapai ambang batas yang telah ditentukan, serta pemberitahuan, peluncuran, dan tim dukungan telah siap. Pertahankan jendela observasi untuk memverifikasi bahwa kegagalan berasal dari klien yang dapat diperbarui, bukan dari perangkat kritis yang tidak teridentifikasi.
Jika protokol beralih ke UDP, apakah masih memerlukan TLS 1.3?
Jangan menerapkan kesimpulan tersebut secara otomatis. RFC 9852 secara eksplisit menargetkan TLS, bukan DTLS; perancangan UDP memerlukan penilaian risiko dan penerapan DTLS yang terpisah. QUIC mengikuti spesifikasinya sendiri, yang memang mewajibkan TLS 1.3.