Gesaan dan konteks
Soalan asas HTTP dan keselamatan ini sesuai untuk peranan backend, platform, SRE dan infrastruktur. Senarionya ialah permintaan TLS 1.3 0-RTT yang sampai ke get laluan: early data mengurangkan masa menunggu jabat tangan (handshake) tetapi boleh dimainkan semula (replay). Jawapan yang kukuh menghubungkan semantik 425, keidempotenan perniagaan dan dasar lompatan demi lompatan (hop-by-hop).
Perkara yang dinilai oleh penemu duga
- Pemahaman tentang faedah prestasi 0-RTT dan risiko replay.
- Sempadan yang tepat antara 425, 429, 503 dan 408.
- Penggunaan kunci idempoten, lejar penyahduplikasian (deduplication ledger), dan carian status untuk kesan sampingan.
- Dasar early-data yang konsisten merentasi get laluan, origin dan tika (instance).
Soalan penjelasan
Mula-mula, sahkan sama ada terdapat bukti early data, sama ada operasi tersebut mempunyai kesan sampingan, sama ada get laluan mengekalkan Early-Data, dan sama ada klien boleh mencuba semula selepas jabat tangan penuh. Kemudian tanya tentang kunci idempoten, kekangan keunikan (uniqueness constraints), rekod penyahduplikasian dan keadaan dikongsi merentasi tika. Permintaan GET masih boleh mempunyai kesan sampingan perniagaan, jadi nama kaedah sahaja bukan bukti keselamatan.
Rangka kerja jawapan 30 saat
TLS 1.3 0-RTT membolehkan klien menghantar early data sebelum jabat tangan selesai, tetapi data tersebut mungkin dimainkan semula. Jika sesuatu permintaan tidak terbukti selamat untuk diproses, pelayan mengembalikan 425 Too Early dan meminta klien mencuba semula selepas jabat tangan; percubaan semula tidak boleh menggunakan early data lagi. Terima early data hanya untuk operasi idempoten yang selamat daripada replay dengan penyahduplikasian. Get laluan dan origin mesti bersetuju mengenai Early-Data: 1, sambil memantau amplifikasi percubaan semula.
Analisis mendalam langkah demi langkah
- Nyatakan risiko. Early data 0-RTT masih disulitkan, tetapi penyerang boleh menyalin dan memainkan semula permintaan yang sah. Risiko teras adalah kesan sampingan pendua, bukan kehilangan kerahsiaan secara langsung.
- Takrifkan 425. Kembalikan 425 apabila pemprosesan semasa fasa early-data tidak selamat. Pelayan tidak seharusnya mengeluarkan 425 tanpa bukti early data; respons ini tidak boleh dicache secara lalai.
- Kelaskan operasi. Periksa kesan sampingan sebenar walaupun untuk operasi membaca. Pembayaran, penghantaran dan perubahan kuota biasanya perlu menunggu jabat tangan penuh. Jika early data diterima, perlukan kunci idempoten, kekangan keunikan, atau lejar penyahduplikasian.
- Tentukan percubaan semula. Klien yang menghantar early data mencuba semula selepas jabat tangan penuh, dan percubaan semula tidak boleh dihantar sebagai early data. Hadkan bilangan percubaan semula dan jumlah masa.
- Kekalkan ketekalan antara lompatan. Perantara yang dipercayai boleh menambah atau memajukan
Early-Data: 1. Get laluan, pengimbang beban (load balancer), dan origin memerlukan sempadan kepercayaan yang sama; jika tidak, satu tika mungkin menunggu sementara tika yang lain melaksanakan kesan sampingan. - Kawal amplifikasi. Semasa beban lampau, respons 425 dan percubaan semula jabat tangan boleh meningkatkan trafik. Hadkan saiz early-data dan keserentakan, serta pantau nisbah 425, kadar percubaan semula, kunci perniagaan pendua dan kependaman jabat tangan.
Jawapan model
Saya akan menganggap Early-Data: 1 sebagai isyarat risiko replay, bukan sebagai permintaan biasa yang disahkan:
POST /payments HTTP/1.1
Early-Data: 1
Idempotency-Key: pay-123Jika operasi pembayaran tidak terbukti selamat daripada replay, saya mengembalikan 425 Too Early dan meminta klien melengkapkan jabat tangan TLS sebelum mencuba semula dengan kunci idempoten yang sama; percubaan semula tidak boleh menggunakan early data lagi. Walaupun untuk operasi yang selamat daripada replay, saya menggunakan kekangan keunikan atau lejar penyahduplikasian untuk mengelakkan pelaksanaan pendua. 425 bukanlah pengehadan kadar (429), ketidaktersediaan sementara yang meluas (503), atau tamat masa klien (408). Get laluan dan origin berkongsi satu dasar dan mencatat ID permintaan, penanda early-data, kiraan percubaan semula dan kunci pendua supaya percubaan semula tidak memburukkan beban lampau.
Kesilapan biasa
- Mengatakan "0-RTT tidak disulitkan" → TLS masih menyulitkannya → risikonya ialah replay.
- Menghantar semula 0-RTT tanpa perubahan selepas 425 → risiko kekal → cuba semula selepas jabat tangan penuh.
- Mengembalikan 425 untuk setiap POST → sesetengah penulisan mempunyai penyahduplikasian yang boleh dipercayai → nilaikan kesan sampingan dan bukti.
- Menganggap 425 sebagai 429 → 425 mengendalikan early data, manakala 429 menandakan pengehadan kadar → gunakan backoff dan makluman yang berasingan.
- Hanya menyemak di get laluan → origin mungkin melaksanakannya secara tidak konsisten → kongsi sempadan kepercayaan dan keadaan.
Soalan susulan
Bagaimanakah anda membezakan 425 daripada 503?
425 menangani risiko replay semasa fasa early-data; 503 bermaksud perkhidmatan tidak dapat mengendalikan permintaan buat sementara waktu. Pilih 425 hanya apabila bukti early-data wujud dan dasar memerlukan menunggu jabat tangan.
Mengapa tidak benarkan GET sahaja?
Nama kaedah HTTP tidak menjamin ketiadaan kesan sampingan perniagaan. Sesetengah permintaan GET mencetuskan pembilang, praambil (prefetch) atau perubahan keadaan, jadi nilaikan kesan sebenar dan penyahduplikasian.
Bagaimanakah get laluan harus menyampaikan maklumat early-data?
Perantara yang dipercayai boleh menambah atau memajukan Early-Data: 1, tetapi ia mesti menghalang klien yang tidak dipercayai daripada memalsukan isyarat tersebut dan memberitahu origin dari mana penanda itu datang dan dasar mana yang terpakai.
Bagaimanakah anda membuktikan bahawa caj tidak boleh berlaku dua kali?
Gunakan kunci idempoten yang sama untuk sisipan unik atau lejar penyahduplikasian, rekod keadaan akhir, buat pertanyaan sebelum mencuba semula, dan selaraskan peristiwa pembayaran dengan pesanan perniagaan selepas itu.