Perintah dan konteks
Anda mengoperasikan koneksi administratif jangka panjang. Sebagian besar permintaan harus menghindari pemrosesan sertifikat klien, tetapi operasi berisiko tinggi wajib mengidentifikasi klien. Rancang autentikasi klien pasca-handshake TLS 1.3 dan jelaskan batasannya dibandingkan dengan mutual TLS selama handshake awal.
Apa yang sedang diuji oleh pewawancara
Jawaban harus memperlakukan autentikasi pasca-handshake sebagai alur pesan TLS 1.3 opsional, bukan sebagai koneksi TLS kedua. Cakup hal klien yang mengiklankan kapabilitas post_handshake_auth di ClientHello awalnya, server yang mengirim CertificateRequest kemudian, klien yang mengembalikan rantai sertifikatnya dan CertificateVerify, penanganan kegagalan, serta pengikatan hasilnya ke HTTP/2, HTTP/3, atau permintaan aplikasi.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Cakupan autentikasi
Tanyakan apakah autentikasi dilakukan sekali per koneksi, sekali per permintaan berisiko tinggi, atau bergantung pada penyewa (tenant). Menyimpannya dalam cache terlalu lama akan memperbesar celah pencabutan (revocation window); memintanya terlalu sering akan menambah biaya validasi sertifikat dan pesan protokol.
Batasan protokol dan implementasi
Konfirmasikan apakah koneksi membawa HTTP/1.1, HTTP/2, HTTP/3, atau protokol kustom, dan apakah pustaka TLS mengekspos API pasca-handshake. Aplikasi harus memblokir operasi yang dilindungi hingga autentikasi selesai.
Kebijakan kegagalan dan pencabutan
Tentukan apakah sertifikat yang kedaluwarsa, CA yang tidak dikenal, tanda tangan yang buruk, atau kapabilitas yang tidak didukung akan menolak satu permintaan, menutup koneksi, atau mempertahankan sesi berhak istimewa rendah. Identifikasi sumber OCSP, sertifikat berdurasi pendek, atau daftar pencabutan (CRL).
Kerangka jawaban 30 detik
"Autentikasi pasca-handshake TLS 1.3 mengharuskan klien untuk mengiklankan post_handshake_auth di ClientHello awalnya. Server kemudian mengirimkan CertificateRequest; klien mengembalikan Certificate, CertificateVerify, dan Finished. Server memvalidasi rantai, penggunaan, tanda tangan, dan status pencabutan sebelum mengikat identitas ke permintaan berikutnya. Jika kapabilitas tidak dinegosiasikan atau validasi gagal, kebijakan harus menolak operasi yang dilindungi atau menutup koneksi daripada menurunkannya secara diam-diam (silent downgrade)."
Jawaban mendalam langkah demi langkah
Langkah 1: Negosiasikan kapabilitas dan buat sesi terenkripsi yang belum terautentikasi
Klien mengiklankan dukungan di ClientHello. Server menyelesaikan handshake TLS 1.3 biasa tetapi menandai koneksi sebagai terenkripsi dan belum terautentikasi klien. Klien yang tidak mengiklankan kapabilitas tersebut tidak dapat diminta untuk menyerahkan sertifikat di kemudian hari; rutekan ke hak istimewa rendah atau sambungkan ulang sesuai kebijakan.
Langkah 2: Kirim CertificateRequest ketika kebijakan mewajibkannya
Ketika endpoint berisiko tinggi atau kebijakan penyewa mewajibkan identitas, server mengirimkan CertificateRequest dengan algoritma tanda tangan dan batasan certificate authority yang dapat diterima. Mesin status (state machine) TLS harus melakukan serialisasi proses ini dengan penulisan aplikasi sehingga stream yang konkuren tidak dapat mengamati status yang baru terbarui sebagian.
Langkah 3: Validasi respons klien
Klien mengirimkan rantai sertifikatnya, CertificateVerify, dan Finished. Validasi rantai, identitas SAN atau URI, penggunaan kunci (key usage), algoritma tanda tangan, masa berlaku, dan pencabutan. Hanya setelah itu lampirkan identitas, sidik jari sertifikat, dan waktu autentikasi ke konteks koneksi. Permintaan sensitif yang tiba lebih awal harus diantrekan atau ditolak.
Langkah 4: Tangani kegagalan dan percobaan ulang (retries)
Untuk kapabilitas yang tidak didukung, sertifikat yang hilang, tanda tangan tidak valid, atau pencabutan, kembalikan kesalahan aplikasi, kirim peringatan TLS (TLS alert), atau tutup koneksi sesuai kebijakan. Batasi percobaan ulang berdasarkan jumlah dan waktu. Jangan pernah mengubah permintaan berisiko tinggi yang gagal menjadi permintaan anonim secara otomatis. Catat kelas kesalahan dan versi konfigurasi tanpa menyertakan materi kunci privat atau konten sertifikat yang tidak perlu.
Langkah 5: Perhitungkan pemulihan sesi (resumption), konkurensi, dan migrasi
Pemulihan sesi tidak secara otomatis membuktikan bahwa otorisasi aplikasi saat ini masih valid. Evaluasi ulang kebijakan pada koneksi yang dipulihkan. Dengan multipleksing HTTP/2, satu stream dapat memicu autentikasi sementara stream lain mengirim permintaan, jadi tentukan batasan pemblokirannya. Pastikan implementasi QUIC/TLS HTTP/3 mendukung alur pesan tersebut sebelum menjanjikannya.
Langkah 6: Operasikan kepercayaan dan materi kunci
Gunakan CA klien khusus, sertifikat berumur pendek, dan peluncuran trust-store yang dapat diaudit. Selama rotasi CA, pertahankan jendela kepercayaan ganda (dual-trust window) dan jalur pengembalian (rollback path). Pisahkan izin untuk kunci privat server, trust store, dan publikasi kebijakan; verifikasi klien tidak boleh memberikan akses ke operasi kunci server.
Langkah 7: Uji dan amati
Bangun matriks klien dengan dan tanpa kapabilitas tersebut. Uji keberhasilan, sertifikat kedaluwarsa, tanda tangan yang salah, pencabutan, batas waktu (timeout), stream konkuren, dan pemulihan sesi. Pantau tingkat CertificateRequest, tingkat keberhasilan, kelas kegagalan, latensi autentikasi, permintaan terlindungi yang ditolak, dan penutupan koneksi. Pastikan log pengujian tidak mengekspos kunci privat atau payload sensitif yang lengkap.
Contoh jawaban berkualitas tinggi
Saya akan memodelkan dua status: terenkripsi-tetapi-belum-terautentikasi dan terautentikasi-klien. Klien harus mengiklankan post_handshake_auth di ClientHello sebelum server dapat mengirim CertificateRequest. Klien mengembalikan rantainya, CertificateVerify, dan Finished; server memeriksa CA, SAN, penggunaan, tanda tangan, masa berlaku, dan pencabutan sebelum mengikat identitas ke permintaan berisiko tinggi.
Jika kapabilitas tidak dinegosiasikan atau validasi gagal, tolak operasi yang dilindungi; jangan turunkan versi secara diam-diam. Bekukan stream HTTP/2 yang dilindungi saat autentikasi sedang berlangsung, dan verifikasi dukungan pustaka untuk HTTP/3. Evaluasi ulang otorisasi setelah pemulihan sesi. Luncurkan dengan matriks klien dan amati inisiasi, keberhasilan, alasan kegagalan, latensi, dan perilaku pencabutan.
Kesalahan umum
- Kesalahan: Mengasumsikan bahwa koneksi yang sudah terbentuk berarti klien telah terautentikasi. → Mengapa ini gagal: Enkripsi dan identitas klien adalah status yang terpisah. → Solusi: Lacak kedua status secara eksplisit.
- Kesalahan: Mewajibkan sertifikat dari klien yang tidak menegosiasikan kapabilitas tersebut. → Mengapa ini gagal: Kapabilitas harus diiklankan di ClientHello awal. → Solusi: Gunakan kebijakan berhak istimewa rendah atau sambung ulang.
- Kesalahan: Mengeksekusi permintaan setelah autentikasi gagal. → Mengapa ini gagal: Pesan autentikasi tiba secara asinkron dan tidak mengamankan pekerjaan secara retroaktif. → Solusi: Blokir stream yang dilindungi hingga validasi selesai.
- Kesalahan: Menggunakan kembali identitas koneksi lama untuk otorisasi penyewa baru. → Mengapa ini gagal: Pemulihan sesi dan perubahan kebijakan dapat membatalkan status aplikasi yang lama. → Solusi: Evaluasi ulang menggunakan versi otorisasi.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Mengapa mutual TLS awal masih umum digunakan?
Mutual TLS awal memilih dan memverifikasi identitas sebelum handshake berakhir, sehingga status dan kompatibilitasnya lebih sederhana ketika setiap permintaan memerlukan autentikasi. Autentikasi pasca-handshake cocok untuk koneksi jangka panjang di mana hanya sebagian kecil operasi yang memerlukan identitas tambahan, dengan konsekuensi bertambahnya status dan aturan konkurensi.
Pertanyaan lanjutan 2: Bisakah ini menggantikan otorisasi aplikasi?
Tidak. Ini hanya membuktikan kepemilikan kunci privat dan rantai sertifikat yang valid. Aplikasi tetap memetakan SAN, penyewa, peran, operasi, dan status pencabutan ke keputusan otorisasi serta mencatat versi keputusan tersebut.
Pertanyaan lanjutan 3: Haruskah klien tanpa sertifikat diputuskan koneksinya?
Tidak selalu. Kebijakan dapat mempertahankan sesi berhak istimewa rendah dan menolak permintaan yang dilindungi. Bidang manajemen (management plane) yang memerlukan autentikasi berkelanjutan harus mengembalikan kesalahan yang jelas dan menutup koneksi. Buat pilihan tersebut dapat diaudit dan diobservasi.
Pertanyaan lanjutan 4: Bagaimana Anda membuktikan bahwa suatu pustaka mendukung alur ini?
Periksa API berversi dan pengujian interoperabilitas untuk negosiasi ekstensi, CertificateRequest, sertifikat tidak valid, stream konkuren, dan pemulihan sesi. Satu flag konfigurasi saja tidak membuktikan bahwa seluruh mesin status telah diimplementasikan.