Prompt dan konteks
Sebuah payment API mengaktifkan TLS 1.3 session resumption. Beberapa permintaan tiba sebelum handshake selesai dan gateway mengembalikan 425 Too Early. Jelaskan permintaan mana yang boleh menggunakan early data, cara mencegah efek samping replay, cara proxy memberi sinyal tersebut, dan kapan klien boleh mencoba ulang (retry).
Apa yang dievaluasi oleh pewawancara
- Memahami bahwa 0-RTT mengurangi latensi tetapi tidak memberikan perlindungan replay seperti handshake biasa.
- Membedakan secara benar antara 425, timeout jaringan, dan penolakan bisnis, serta menggunakan
Early-Data: 1. - Menghubungkan idempotency key, jendela deduplikasi, kebijakan gateway, dan state machine server.
- Membuktikan dengan metrik dan uji simulasi (drill) bahwa percobaan ulang tidak mendebit dua kali.
Pertanyaan klarifikasi
- Klien, CDN, gateway, atau origin mana yang mengakhiri TLS dan dapat mengetahui bahwa data tersebut adalah early data?
- Apakah permintaan tersebut berupa GET atau baca, ataukah melakukan penagihan, pengiriman, pemberian hak, atau memublikasikan efek samping?
- Apakah ada idempotency key yang unik secara global, berapa lama ia disimpan, dan apakah dibagikan lintas wilayah (cross-region)?
- Apakah satu gateway menghasilkan 425, dan dapatkah setiap SDK memahaminya serta menyusun ulang body permintaan?
- Bagaimana keselarasan antara batas waktu retry, masa berlaku otorisasi pembayaran, dan status yang terlihat oleh pengguna?
Jawaban 30 detik
0-RTT memungkinkan klien yang melanjutkan sesi TLS 1.3 mengirim data aplikasi lebih awal, tetapi penyerang dapat memutar ulang (replay) data tersebut. Server harus menolak early data untuk permintaan yang menimbulkan efek samping; perantara yang mendukung dapat memberi sinyal dengan Early-Data: 1 dan origin dapat mengembalikan 425. Setelah full handshake, klien hanya mencoba ulang saat replay aman. Untuk penulisan pembayaran, klien terlebih dahulu memeriksa hasil idempotensi atau menunggu konfirmasi bisnis; 425 bukan bukti bahwa penagihan gagal.
Jawaban mendalam
Langkah 1: Tentukan batasan 0-RTT
Melanjutkan sesi TLS 1.3 mengizinkan early data untuk menghemat round trip. Server tidak boleh memperlakukannya sebagai bukti baru yang tidak dapat diputar ulang: penyerang dapat menyalin bita yang sama dan mengirimkannya kembali selama jendela waktu yang diizinkan.
Langkah 2: Klasifikasikan efek samping
GET publik, kueri hanya-baca, atau permintaan yang benar-benar idempoten dapat mempertimbangkan early data jika kondisi protokol dan bisnis mengizinkannya. Penagihan, pembuatan pesanan, pemberian hak, atau publikasi pesan harus menonaktifkannya kecuali server memiliki idempotensi yang andal dan deduplikasi atomik.
Langkah 3: Pahami Early-Data dan 425
Perantara yang mendukung early data dapat menambahkan Early-Data: 1 saat meneruskannya. Origin yang tidak bersedia menerima risiko replay akan mengembalikan 425, yang berarti permintaan tiba terlalu awal; klien harus mengirim ulang setelah handshake selesai. Ketiadaan header tersebut bukan bukti nol risiko replay, jadi verifikasi penyebaran (deployment) secara menyeluruh.
Langkah 4: Rancang kebijakan gateway
Gateway memelihara daftar izin (allowlist) berdasarkan metode, jalur, dan jenis autentikasi. Gateway menolak early data pada jalur pembayaran, inventaris, dan perubahan otorisasi, sambil mencatat status koneksi untuk jalur pembacaan. Gateway harus mempertahankan 425 dan tidak mengubahnya menjadi 500 generik.
Langkah 5: Rancang idempotensi dan deduplikasi
Klien membuat kunci yang tidak dapat diprediksi untuk setiap tujuan bisnis. Server secara atomik menerapkan efek samping dan hasil deduplikasi, atau menggunakan batasan atomik yang setara. Kunci duplikat mengembalikan hasil pertama dan tidak akan pernah menagih lagi. TTL mencakup retry jaringan maksimum, penundaan antrean, dan rekonsiliasi.
Langkah 6: Tentukan percobaan ulang (retry) yang aman
Setelah 425, buat koneksi penuh dan kirim ulang hanya jika batas waktu masih valid dan body dapat disusun ulang. GET dapat mencoba ulang secara otomatis. Permintaan pembayaran dengan idempotency key terlebih dahulu membaca statusnya; penulisan tanpa perlindungan replay dialihkan ke konfirmasi bisnis. Batasi retry per tujuan dan gunakan backoff.
Langkah 7: Verifikasi dan amati
Catat volume early data, rasio 425, tingkat retry per jalur, kunci duplikat, tagihan yang berhasil, dan perbedaan rekonsiliasi. Injeksikan kegagalan proxy dan klien untuk menguji penolakan, retry dengan full-handshake, timeout, pengiriman duplikat, dan deduplikasi lintas wilayah. Hasil pengujian harus menunjukkan paling banyak satu efek samping per tujuan bisnis.
Jawaban model
Saya akan memasukkan penulisan pembayaran ke dalam daftar tolak (denylist) early data. Jika terminator TLS menerima early data, ia meneruskan Early-Data: 1; origin mengembalikan 425 untuk penulisan tersebut dan menyimpan ID permintaan untuk diagnostik. Setelah full handshake, klien tidak memutar ulang secara membabi buta: klien mengueri pesanan atau tagihan berdasarkan idempotency key dan hanya mencoba ulang sekali ketika status tidak diketahui dan batas waktu memungkinkan. Server menyimpan kunci, hasil bisnis, dan catatan deduplikasi secara atomik, dengan batasan lintas wilayah. GET hanya-baca dapat mencoba ulang secara otomatis. Saya memantau respons 425, kunci duplikat, dan perbedaan rekonsiliasi, serta melakukan simulasi pada jalur tersebut untuk membuktikan tidak ada penagihan ganda.
Kesalahan umum
- Mengasumsikan TLS 1.3 0-RTT otomatis aman dari replay.
- Mencoba ulang 425 tanpa henti atau mengubahnya menjadi 500.
- Menentukan keamanan hanya dari metode HTTP; beberapa GET masih menimbulkan efek samping.
- Menyimpan idempotency key hanya di sisi klien tanpa deduplikasi atomik di sisi server.
- Menganggap timeout sebagai bukti bahwa server tidak melakukan apa pun, alih-alih mengueri statusnya.
Pertanyaan dan jawaban lanjutan
Lanjutan 1: Bagaimana perbedaan 425 dengan 503?
425 menangani risiko replay pada early data dan meminta penilaian ulang setelah full handshake. 503 berarti ketidaktersediaan layanan sementara; kebijakan percobaannya bergantung pada kapasitas dan Retry-After.
Lanjutan 2: Siapa yang menambahkan Early-Data?
Perantara yang memahami mekanisme ini menambahkan Early-Data: 1 saat meneruskan early data ke origin. Verifikasi titik terminasi TLS dan pastikan proxy tidak menghilangkan maupun memalsukan sinyal tersebut.
Lanjutan 3: Apakah idempotency key cukup untuk pembayaran 0-RTT?
Tidak. Kunci harus tidak dapat diprediksi, disimpan secara atomik bersama hasilnya, dideduplikasi di seluruh wilayah yang diperlukan, disimpan cukup lama, dan terbukti mengembalikan hasil yang sama pada data duplikat.
Lanjutan 4: Mengapa melakukan kueri setelah timeout pada klien?
Timeout hanya membuktikan bahwa klien tidak menerima respons. Mengueri status idempotensi membedakan antara berhasil, sedang diproses, dan belum dieksekusi, sehingga menghindari penagihan kedua.
Lanjutan 5: Bagaimana cara Anda melakukan canary deployment?
Mulailah dengan jalur hanya-baca dan sebagian kecil klien. Lacak 425 dan keberhasilan retry berdasarkan jalur; nonaktifkan early data secara otomatis jika terjadi efek samping duplikat, anomali rekonsiliasi, atau hilangnya sinyal proxy.