Perintah dan konteks
Pertanyaan dasar HTTP dan keamanan ini cocok untuk peran backend, platform, SRE, dan infrastruktur. Skenarionya adalah permintaan 0-RTT TLS 1.3 yang mencapai gateway: early data mengurangi waktu tunggu handshake tetapi dapat di-replay (diputar ulang). Jawaban yang kuat menghubungkan semantik 425, idempotensi bisnis, dan kebijakan hop-by-hop.
Hal yang dievaluasi pewawancara
- Pemahaman tentang manfaat performa 0-RTT dan risiko replay-nya.
- Batasan yang tepat antara 425, 429, 503, dan 408.
- Penggunaan idempotency key, buku besar deduplikasi (deduplication ledger), dan pencarian status untuk efek samping.
- Kebijakan early-data yang konsisten di seluruh gateway, origin, dan instance.
Pertanyaan klarifikasi
Pertama, konfirmasikan bahwa terdapat bukti early data, apakah operasi tersebut memiliki efek samping, apakah gateway mempertahankan Early-Data, dan apakah klien dapat melakukan retry setelah handshake penuh. Kemudian tanyakan tentang idempotency key, batasan keunikan (uniqueness constraints), rekaman deduplikasi, dan status bersama antar instance. Permintaan GET masih dapat memiliki efek samping bisnis, sehingga nama method saja bukan merupakan bukti keamanan.
Kerangka jawaban 30 detik
0-RTT TLS 1.3 memungkinkan klien mengirimkan early data sebelum handshake selesai, namun data tersebut dapat di-replay. Jika suatu permintaan belum terbukti aman untuk diproses, server mengembalikan 425 Too Early dan meminta klien untuk melakukan retry setelah handshake; retry tersebut tidak boleh menggunakan early data lagi. Terima early data hanya untuk operasi idempoten yang aman dari replay dengan deduplikasi. Gateway dan origin harus menyetujui Early-Data: 1, sambil memantau amplifikasi retry.
Analisis mendalam langkah demi langkah
- Nyatakan risikonya. Early data 0-RTT tetap terenkripsi, namun penyerang dapat menyalin dan memutar ulang (replay) permintaan yang valid. Risiko utamanya adalah efek samping ganda, bukan hilangnya kerahasiaan secara langsung.
- Definisikan 425. Kembalikan 425 jika pemrosesan selama fase early-data tidak aman. Server sebaiknya tidak mengeluarkan 425 tanpa adanya bukti early data; respons ini tidak dapat di-cache secara default.
- Klasifikasikan operasi. Periksa efek samping nyata bahkan untuk operasi baca (read). Pembayaran, pengiriman, dan perubahan kuota biasanya harus menunggu handshake penuh. Jika early data diterima, wajibkan idempotency key, batasan keunikan, atau buku besar deduplikasi.
- Tentukan mekanisme retry. Klien yang mengirimkan early data melakukan retry setelah handshake penuh, dan retry tersebut tidak boleh dikirim sebagai early data. Batasi jumlah retry dan total waktu.
- Jaga konsistensi antar-hop. Perantara tepercaya dapat menambahkan atau meneruskan
Early-Data: 1. Gateway, load balancer, dan origin memerlukan batas kepercayaan yang sama; jika tidak, satu instance mungkin menunggu sementara instance lain mengeksekusi efek samping. - Kendalikan amplifikasi. Selama beban berlebih (overload), respons 425 dan retry handshake dapat mengamplifikasi lalu lintas. Batasi ukuran early-data dan konkurensi, serta pantau rasio 425, tingkat retry, duplikasi business key, dan latensi handshake.
Jawaban model
Saya akan memperlakukan Early-Data: 1 sebagai sinyal risiko replay, bukan sebagai permintaan biasa yang terkonfirmasi:
POST /payments HTTP/1.1
Early-Data: 1
Idempotency-Key: pay-123Jika operasi pembayaran belum terbukti aman dari replay, saya mengembalikan 425 Too Early dan meminta klien menyelesaikan handshake TLS sebelum melakukan retry dengan idempotency key yang sama; retry tersebut tidak boleh menggunakan early data lagi. Bahkan untuk operasi yang aman dari replay, saya menggunakan batasan keunikan atau buku besar deduplikasi untuk mencegah eksekusi ganda. 425 bukanlah rate limiting (429), ketidaktersediaan sementara secara umum (503), atau batas waktu klien / client timeout (408). Gateway dan origin berbagi satu kebijakan yang sama dan mencatat ID permintaan, penanda early-data, jumlah retry, dan kunci duplikat agar retry tidak memperparah overload.
Kesalahan umum
- Mengatakan "0-RTT tidak terenkripsi" → TLS tetap mengenkripsinya → risikonya adalah replay.
- Mengirim ulang 0-RTT tanpa perubahan setelah 425 → risiko tetap ada → lakukan retry setelah handshake penuh.
- Mengembalikan 425 untuk setiap POST → beberapa penulisan memiliki deduplikasi yang andal → evaluasi efek samping dan buktinya.
- Memperlakukan 425 sebagai 429 → 425 menangani early data, sedangkan 429 menandakan rate limiting → gunakan backoff dan peringatan terpisah.
- Hanya memeriksa di gateway → origin dapat mengeksekusi secara tidak konsisten → bagikan batas kepercayaan dan status.
Pertanyaan lanjutan
Bagaimana Anda membedakan 425 dari 503?
425 menangani risiko replay selama fase early-data; 503 berarti layanan sementara tidak dapat menangani permintaan. Pilih 425 hanya jika bukti early-data ada dan kebijakan mewajibkan menunggu handshake.
Mengapa tidak hanya mengizinkan GET?
Nama method HTTP tidak menjamin ketiadaan efek samping bisnis. Beberapa permintaan GET memicu penghitung (counter), prefetch, atau perubahan status, jadi evaluasi efek aktual dan deduplikasinya.
Bagaimana gateway harus meneruskan informasi early-data?
Perantara tepercaya dapat menambahkan atau meneruskan Early-Data: 1, namun harus mencegah klien yang tidak tepercaya memalsukan sinyal tersebut dan memberi tahu origin dari mana penanda itu berasal dan kebijakan mana yang berlaku.
Bagaimana Anda membuktikan bahwa tagihan tidak dapat terjadi dua kali?
Gunakan idempotency key yang sama untuk penyisipan unik (unique insert) atau buku besar deduplikasi, catat status akhir, lakukan kueri sebelum retry, dan rekonsiliasikan peristiwa pembayaran dengan pesanan bisnis setelahnya.