Temu duga umum: Bagaimanakah anda mereka bentuk relay dan gateway Oblivious HTTP?

Soalan dan skop

Klien telemetri mahu perkhidmatan sasaran tidak dapat mengaitkan permintaan dengan identiti klien manakala nod pemajuan tidak boleh membaca kandungan permintaan. Reka bentuk klien, relay, gateway dan sasaran OHTTP, yang merangkumi penemuan kunci, enkapsulasi HPKE, pengendalian ralat, pertahanan main semula, pemetaan sumber, had kadar (rate limits) dan pemantauan.

RFC 9458 mempiawaikan pemajuan mesej HTTP yang disulitkan: relay melihat sambungan klien, manakala gateway menyahsulit dan memanggil sasaran, jadi tiada pihak yang secara bebas boleh mengetahui kedua-dua identiti dan kandungan. OHTTP bukan rangkaian tanpa nama; panjang mesej, pemasaan (timing), pakatan sulit (collusion) relay/gateway, metadata klien dan pengecam aplikasi masih memerlukan pengendalian berasingan.

Perkara yang diuji oleh penemu duga

Mentakrifkan apa yang boleh dilihat oleh Client, Relay, Gateway dan Target serta di mana had kepercayaan berakhir.
Menerangkan kunci awam gateway, enkapsulasi permintaan/respons HPKE dan jenis media (media types).
Mereka bentuk pertahanan main semula, had saiz permintaan, tamat masa (timeouts) dan pemetaan ralat.
Mengendalikan pemetaan sumber satu-ke-satu relay/gateway, analisis trafik dan risiko pakatan sulit.
Mengendalikan putaran kunci, pengesahan caching, percubaan semula (retries) dan penyelewengan jam klien (clock skew).
Mengesahkan dengan metrik penerimaan, kegagalan dekapsulasi, penolakan main semula, kependaman (latency) dan taburan panjang mesej.

Soalan untuk dijelaskan terlebih dahulu

Adakah ini telemetri satu hala, bacaan awam, atau operasi tulis bernilai tinggi? Operasi tulis yang sensitif memerlukan pengesahan dan kawalan main semula yang lebih kukuh.
Adakah relay dan gateway dikendalikan oleh pihak yang berbeza, atau bolehkah satu organisasi memiliki kedua-duanya?
Adakah sasaran mengembalikan hasil yang berbeza mengikut kebenaran pengguna, penyewa (tenant), atau rantau?
Apakah had saiz permintaan, tetingkap kelompok (batching), kependaman dan toleransi kehilangan?
Bolehkah klien menemui semula konfigurasi selepas kunci tamat tempoh, dan medan log manakah yang mesti dipadamkan (redacted)?

Jawapan 30 saat

Saya akan menetapkan empat sempadan: klien menyambung ke relay, relay hanya memajukan mesej yang dienkapsulasi, dan gateway menyahsulitkannya sebelum memanggil sasaran. Klien menemui konfigurasi kunci gateway dan menggunakan HPKE untuk mengenkapsulasi HTTP binari; respons dienkapsulasi dalam arah sebaliknya. Gateway menggunakan tetingkap masa, pengecam permintaan unik, atau keidempotenan aplikasi untuk menolak main semula, manakala relay mengehadkan sumber sambungan dan mesej. Putar kunci dengan tempoh bertindih dan pantau kegagalan dekapsulasi, penolakan main semula, kependaman dan taburan panjang mesej; jangan bentangkan OHTTP sebagai perlindungan terhadap pakatan sulit atau analisis trafik.

Perbincangan terperinci langkah demi langkah

1. Takrifkan empat tanggungjawab

Client mengetahui sumber sasaran dan kunci awam gateway. Relay mengetahui sambungan rangkaian klien tetapi tidak boleh membaca kandungan yang dienkapsulasi. Gateway menyahsulit dan menghantar HTTP biasa ke Target, yang melihat gateway sebagai sumbernya. Asingkan penggunaan (deployment), log dan kebenaran akses supaya satu pihak tidak boleh mengaitkan identiti dan kandungan secara mudah.

2. Temui dan sahkan konfigurasi kunci

Klien memperoleh konfigurasi kunci gateway yang mengandungi pengecam kunci, algoritma HPKE dan kunci awam. Ia memerlukan sumber yang disahkan, versi dan tarikh luput; tolak algoritma yang tidak disokong dan kunci lapuk. Semasa putaran kunci, terbitkan kunci lama dan baharu bersama-sama sehingga cache klien dan tetingkap permintaan telah tamat.

3. Enkapsulasi permintaan dan respons

Klien mengekod permintaan HTTP binari dan mengenkapsulasikannya dengan HPKE sebagai muatan message/ohttp-req. Gateway mendekapsulasi dan mengesahkan kaedah, sumber sasaran, saiz dan jenis kandungan. Ia mengenkapsulasi respons sebagai message/ohttp-res. Relay tidak boleh menghuraikan HTTP dalaman atau menghalakan berdasarkan status teks biasa.

text

Client -- TLS --> Relay -- opaque OHTTP --> Gateway -- HTTP --> Target
Client <-- opaque response -- Relay <-- OHTTP response -- Gateway

4. Kendalikan pengesahan, main semula dan keidempotenan

OHTTP menyembunyikan identiti rangkaian; ia tidak mengesahkan pengguna perniagaan. Untuk operasi tulis, gunakan tandatangan aplikasi, nonce sekali guna, tetingkap masa, atau kunci keidempotenan. Gateway mengekalkan keadaan pengesanan main semula minimum dan menolak mesej enkapsulasi yang berulang. Kelompok telemetri boleh membawa ID peristiwa idempoten supaya percubaan semula tidak dikira dua kali.

5. Kendalikan ralat dan pemetaan sumber

Jika dekapsulasi gagal, gateway mengembalikan ralat kunci atau enkapsulasi yang berstruktur tanpa mendedahkan butiran kunci peribadi. Ralat perniagaan sasaran dihantar kembali di dalam respons OHTTP. Pemetaan sumber relay-ke-gateway hendaklah tetap dan boleh disahkan supaya mesej tidak sampai ke sasaran yang salah. Guna pakai had berasingan untuk tamat masa, saiz dan beban lampau pada setiap lapisan.

6. Nilaikan kebocoran privasi dan analisis trafik

Penyulitan tidak menghalang relay daripada melihat IP klien, pemasaan dan panjang mesej, atau gateway daripada melihat kekerapan permintaan dan medan aplikasi yang dinyahsulit. Pelapik (padding), pengelompokan (batching), had kadar dan log berasingan boleh mengurangkan korelasi dengan mengorbankan kependaman dan kos. Jangan mendakwa bahawa OHTTP mengatasi pakatan sulit relay/gateway.

7. Kenari (canary), pantau dan sandaran (fallback)

Mulakan dengan kohort klien yang kecil dan sumber relay/gateway khusus. Jejaki capaian konfigurasi, kejayaan dekapsulasi, penolakan main semula, sasaran 5xx, kependaman p95, baldi saiz mesej dan kadar sandaran. Semasa insiden, lumpuhkan OHTTP secara terhad mengikut sasaran atau versi klien; sandaran HTTPS biasa memerlukan semakan privasi. Simpan ID konfigurasi, kelas ralat dan cincangan (hashes) permintaan, bukan medan identiti dalaman.

Contoh jawapan berkualiti tinggi

Saya akan membahagikan klien, relay, gateway dan sasaran kepada empat domain tanggungjawab. Klien memperoleh dan mengesahkan konfigurasi kunci HPKE gateway, mengenkapsulasi HTTP binari dan menghantarnya ke relay. Relay memajukan bait legap (opaque bytes). Gateway mendekapsulasi, memeriksa saiz dan pemetaan sumber, serta memanggil sasaran dengan identitinya sendiri; respons dienkapsulasi semasa perjalanan pulang.

OHTTP tidak menyediakan pengesahan perniagaan atau membatalkan pakatan sulit relay/gateway. Oleh itu, operasi tulis memerlukan tandatangan aplikasi, nonce, atau kunci keidempotenan, dengan pemeriksaan main semula tetingkap masa gateway. Putar kunci dengan tetingkap bertindih dan kekang sambungan relay serta sumber mesej. Laksanakan kenari bagi memantau kegagalan dekapsulasi, penolakan main semula, kependaman, taburan saiz dan ralat perniagaan; benarkan sandaran HTTPS biasa hanya selepas semakan privasi yang eksplisit.

Kesilapan biasa

Menganggap relay sebagai proksi penyahsulitan → sempadan privasi hilang → biarkan ia mengendalikan sambungan luar dan mesej legap sahaja.
Menganggap OHTTP mengesahkan pengguna → sasaran tidak dapat mengenal pasti entiti perniagaan yang sah → tambah tandatangan aplikasi atau token kebenaran.
Mengabaikan panjang mesej dan pemasaan → analisis trafik masih boleh mengaitkan permintaan → gunakan pelapik dan pengelompokan sambil mengukur kos kependaman.
Mencuba semula operasi tulis tanpa keidempotenan → telemetri dikira dua kali atau kesan sampingan berulang → gunakan nonce, ID peristiwa dan tetingkap main semula.
Berkongsi log relay dan gateway yang boleh dipautkan → satu pihak boleh memulihkan identiti dan kandungan → asingkan pengendali, medan dan kebenaran akses.

Soalan susulan dan jawapan

Bolehkah OHTTP menghalang pakatan sulit relay dan gateway?

Tidak. Protokol ini bergantung pada kepercayaan terhad dan pengasingan operasi. Pihak yang berpakat sulit boleh mengaitkan identiti sambungan dengan kandungan yang dinyahsulit, jadi organisasi, log dan kawalan akses mesti kekal bebas.

Bagaimanakah gateway menghalang main semula?

Gunakan tetingkap masa, nonce, ID peristiwa idempoten, atau tandatangan aplikasi untuk operasi tulis; kekalkan keadaan pengesanan minimum dan tolak mesej terenkapsulasi yang berulang. TLS pada setiap sambungan sahaja tidak menghalang main semula rentas sambungan.

Mengapakah pemetaan sumber diperlukan?

Relay mesti memajukan permintaan yang dienkapsulasi kepada sumber gateway/sasaran yang dimaksudkan. Pemetaan tetap menjadikan sempadan kunci, dasar, had kadar dan audit boleh disahkan serta menghalang penghantaran ke gateway yang tidak serasi.

Bagaimanakah anda memutar kunci awam gateway?

Terbitkan konfigurasi baharu berversi yang mempunyai tarikh luput sambil mengekalkan kunci lama sepanjang tetingkap cache, pengelompokan dan percubaan semula. Perhatikan capaian dan kegagalan dekapsulasi mengikut ID kunci, kemudian tamatkan kunci peribadi lama.

Adakah OHTTP sesuai untuk operasi tulis bernilai tinggi?

Hanya dengan berhati-hati. Ia menyembunyikan identiti rangkaian tetapi tidak menggantikan pengesahan, kebenaran, keidempotenan, atau audit. Buktikan entiti aplikasi dan sempadan main semula sebelum menerima kompromi kependaman dan privasinya.

Apakah yang perlu direkodkan oleh pemantauan?

Rekodkan ID konfigurasi, sumber relay/gateway, kelas ralat, baldi saiz permintaan, penolakan main semula dan kependaman hujung-ke-hujung. Jangan log domain dalaman, pengecam pengguna, atau kandungan terenkapsulasi mentah secara lalai.