Perintah dan konteks
Rantai sertifikat TLS menghabiskan byte handshake; rantai yang besar dapat menambah fragmentasi, kehilangan paket, dan biaya round-trip awal QUIC. RFC 8879 mendefinisikan ekstensi compress_certificate agar endpoint dapat menegosiasikan algoritma dan mengirim pesan Certificate yang dikompresi. Rancang server yang siap diterapkan dengan batas dekompresi, penanganan ketidakcocokan algoritma, dan fallback kompatibilitas.
Apa yang sedang diuji oleh pewawancara
Poin yang dinilai adalah membedakan kompresi pesan sertifikat dari kompresi data aplikasi, memahami arah ekstensi, registrasi algoritma, pemeriksaan panjang setelah dekompresi, dan semantik rantai sertifikat yang tidak berubah. Jawaban yang kuat mempertimbangkan trade-off CPU/bandwidth antara Brotli dan Zstandard serta kehabisan sumber daya akibat input terkompresi yang berbahaya.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Cakupan protokol dan klien
Konfirmasikan porsi TLS 1.3, DTLS, dan QUIC, apakah klien dapat ditingkatkan versinya, dan apakah middlebox membuang ekstensi yang tidak dikenal. Jalur ekstensi TLS 1.3 tidak dapat diasumsikan berlaku untuk TLS 1.2.
Bentuk rantai sertifikat
Tanyakan tentang panjang rantai, sertifikat duplikat, ekstensi pasca-kuantum atau enterprise, dan rantai khusus penyewa (tenant). Stabilitas menentukan nilai cache kompresi dan pra-komputasi.
Anggaran risiko
Perjelas apakah tujuannya adalah mengurangi byte handshake, mengurangi fragmen awal, atau menurunkan penggunaan daya pada perangkat seluler. Tetapkan anggaran untuk CPU dekompresi, memori, dan ukuran maksimum pesan yang tidak dikompresi.
Kerangka jawaban 30 detik
"Klien mengiklankan algoritma di ClientHello; server hanya memilih irisannya dan mengirim pesan Certificate yang dikompresi. Klien melakukan dekompresi dan melakukan validasi rantai biasa; tanda tangan, nama, dan masa berlaku tidak dilewati. Batasi input terkompresi, output hasil dekompresi, dan waktu CPU untuk mencegah bom dekompresi. Kunci cache berdasarkan rantai dan versi algoritma, lalu lakukan fallback ke Certificate biasa saat tidak didukung atau saat tidak ada irisan. Amati kegagalan, fallback, biaya dekompresi, dan ukuran paket awal; perubahan algoritma harus dapat dibatalkan (reversible)."
Langkah-langkah jawaban mendalam
Langkah 1: Tentukan negosiasi
Klien mencantumkan ID algoritma yang dapat diterima dalam ekstensi dan server memilih satu algoritma yang sama. Jika tidak ada irisan, kirimkan Certificate biasa. Gunakan ID dan semantik yang terdaftar di IANA; jangan pernah menggunakan kembali ID yang tidak dikenal.
Langkah 2: Buat dan simpan rantai terkompresi dalam cache
Kompresi seluruh rantai per algoritma dan simpan dalam cache dengan kunci yang berisi digest rantai, ID algoritma, dan versi implementasi. Batalkan validitas saat ada rotasi sertifikat, perubahan urutan rantai, atau pembaruan algoritma; jangan pernah menerapkan hasil lama ke rantai baru.
Langkah 3: Tetapkan pertahanan dekompresi
Sebelum membaca input, mengalokasikan output, atau mengurai sertifikat, terapkan panjang kompresi maksimum, panjang dekompresi maksimum, jumlah sertifikat maksimum, dan anggaran CPU/waktu. Hentikan handshake jika terjadi pelanggaran; iklan algoritma bukanlah izin untuk memercayai dekompresi tanpa batas.
Langkah 4: Pertahankan validasi sertifikat tanpa perubahan
Dekompresi hanya mengubah representasi. Klien tetap memvalidasi tanda tangan rantai, hostname, masa berlaku, penggunaan kunci (key usage), trust anchor, dan pengikatan TLS. Kesalahan penguraian (parse errors) atau ketidakcocokan rantai harus digagalkan; jangan secara diam-diam menggunakan sertifikat usang dari cache.
Langkah 5: Tangani fallback dan middlebox
Pisahkan antara klien yang tidak didukung, tidak adanya irisan algoritma, data terkompresi yang rusak, dan pelanggaran batas dekompresi. Dua yang pertama dapat menggunakan Certificate biasa; data rusak dan pelanggaran batas harus dicatat dan digagalkan sehingga penyerang tidak dapat memaksakan downgrade diam-diam. Lakukan peluncuran bertahap berdasarkan wilayah, versi klien, dan protokol.
Langkah 6: Seimbangkan CPU dan bandwidth
Melakukan pra-kompresi rantai yang stabil akan mengalihkan biaya CPU ke waktu rilis; rantai penyewa (tenant) dinamis memerlukan kebijakan cache hit dan kedaluwarsa. Bandingkan rasio, kecepatan dekompresi, ketersediaan implementasi, dan dukungan klien daripada hanya memaksimalkan rasio semata.
Langkah 7: Amati dan lakukan latihan
Catat negosiasi, fallback biasa, penolakan dekompresi, waktu handshake, ukuran paket awal, dan penggunaan CPU tanpa mencatat private key. Lakukan latihan rotasi sertifikat, pembatalan validitas cache, output berukuran berlebih, penghapusan algoritma, dan fallback penuh sambil memastikan klien yang tidak didukung tetap dapat terhubung.
Contoh jawaban berkualitas tinggi
Saya akan meminta klien mengiklankan algoritma di ClientHello dan server hanya memilih irisan yang sama, mengirimkan rantai biasa jika tidak ada kecocokan. Simpan output terkompresi dalam cache berdasarkan digest rantai, algoritma, dan versi implementasi, serta batalkan validitasnya saat rotasi. Batasi input, ukuran dekompresi, jumlah sertifikat, dan CPU sebelum penguraian, kemudian lakukan validasi X.509 dan TLS seperti biasa. Gagalkan pesan yang rusak atau berukuran berlebih alih-alih melakukan downgrade secara diam-diam. Lakukan peluncuran bertahap dan pantau fallback, biaya dekompresi, serta penghematan paket awal QUIC; pertahankan tombol nonaktifkan (kill switch) instan untuk algoritma.
Kesalahan umum
- Kesalahan: Menganggap kompresi mengurangi validasi sertifikat. → Alasan: Ini hanya mengubah representasi. → Solusi: Lakukan validasi rantai penuh setelah dekompresi.
- Kesalahan: Hanya membatasi input terkompresi. → Alasan: Input kecil dapat mengembang menjadi output yang sangat besar. → Solusi: Batasi juga output, jumlah sertifikat, dan CPU.
- Kesalahan: Melakukan fallback diam-diam pada setiap kegagalan. → Alasan: Kompatibilitas dan kerusakan akibat serangan berbahaya adalah hal yang berbeda. → Solusi: Lakukan fallback hanya jika tidak didukung/tidak ada irisan; catat log dan gagalkan untuk data rusak atau pelanggaran batas.
- Kesalahan: Mengunci cache hanya berdasarkan hostname. → Alasan: Rotasi, algoritma, dan penyewa dapat mengubah rantai. → Solusi: Sertakan digest rantai, algoritma, dan versi.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Bisakah kompresi sertifikat digunakan dengan TLS 1.2?
RFC 8879 menargetkan TLS 1.3, DTLS 1.3, dan konteks terkait; bidang negosiasi TLS 1.3 miliknya tidak dapat begitu saja diterapkan pada TLS 1.2. Verifikasi versi protokol yang tepat terhadap implementasi dan spesifikasi.
Pertanyaan lanjutan 2: Mengapa panjang hasil dekompresi harus dibatasi?
Rasio yang tinggi memungkinkan penyerang menyebabkan alokasi memori atau beban kerja CPU yang besar dari input yang kecil. Batasan output sangat penting untuk mencegah bom dekompresi dan kehabisan sumber daya.
Pertanyaan lanjutan 3: Apa yang harus dilakukan server ketika algoritma tidak beririsan?
Kirimkan Certificate biasa dan pertahankan handshake standar, sambil mengukur kapabilitas klien. Server tidak boleh memilih algoritma yang tidak diiklankan oleh klien.
Pertanyaan lanjutan 4: Mengapa QUIC lebih memedulikan kompresi sertifikat?
Handshake awal QUIC sensitif terhadap jumlah paket dan kehilangan jalur (path loss); ukuran byte sertifikat yang lebih kecil dapat membuat pesan server awal muat lebih optimal. Evaluasi keuntungan tersebut dengan CPU dekompresi, dukungan klien, dan ukuran rantai.