Pertanyaan dan ruang lingkup
Klien telemetri menginginkan layanan target tidak dapat menghubungkan permintaan dengan identitas klien sementara node penerus tidak dapat membaca konten permintaan. Rancang klien, relay, gateway, dan target OHTTP, yang mencakup penemuan kunci, enkapsulasi HPKE, penanganan error, pertahanan replay, pemetaan sumber daya, batas laju (rate limit), dan pemantauan.
RFC 9458 menstandarisasi penerusan pesan HTTP terenkripsi: relay melihat koneksi klien, sementara gateway mendekripsi dan memanggil target, sehingga tidak ada pihak yang secara independen mengetahui identitas sekaligus konten. OHTTP bukanlah jaringan anonim; panjang pesan, waktu (timing), kolusi relay/gateway, metadata klien, dan pengidentifikasi aplikasi masih memerlukan penanganan terpisah.
Hal yang diuji oleh pewawancara
- Menentukan apa yang dapat dilihat oleh Client, Relay, Gateway, dan Target serta di mana batasan kepercayaan berakhir.
- Menjelaskan kunci publik gateway, enkapsulasi permintaan/respons HPKE, dan jenis media (media types).
- Merancang pertahanan replay, batas ukuran permintaan, batas waktu (timeouts), dan pemetaan error.
- Menangani pemetaan sumber daya satu-ke-satu antara relay/gateway, analisis lalu lintas, dan risiko kolusi.
- Menangani rotasi kunci, caching, percobaan ulang (retries), dan pergeseran waktu jam klien (clock skew).
- Memvalidasi dengan metrik penerimaan, kegagalan dekapsulasi, penolakan replay, latensi, dan distribusi panjang pesan.
Pertanyaan klarifikasi awal
- Apakah ini telemetri satu arah, pembacaan publik, atau penulisan bernilai tinggi? Penulisan sensitif membutuhkan autentikasi dan kontrol replay yang lebih kuat.
- Apakah relay dan gateway dioperasikan oleh pihak yang berbeda, atau dapatkah satu organisasi memiliki keduanya?
- Apakah target mengembalikan hasil yang berbeda berdasarkan otorisasi pengguna, penyewa (tenant), atau wilayah?
- Berapa batas ukuran permintaan, jendela pengelompokan (batching), latensi, dan toleransi kehilangan data?
- Dapatkah klien menemukan kembali konfigurasi setelah masa berlaku kunci habis, dan bidang log mana yang harus disunting (redacted)?
Jawaban 30 detik
Saya akan menetapkan empat batasan: klien terhubung ke relay, relay hanya meneruskan pesan terenkapsulasi, dan gateway mendekripsinya sebelum memanggil target. Klien menemukan konfigurasi kunci gateway dan menggunakan HPKE untuk mengenkapsulasi HTTP biner; respons dienkapsulasi ke arah sebaliknya. Gateway menggunakan jendela waktu, pengidentifikasi permintaan unik, atau idempotensi aplikasi untuk menolak replay, sementara relay membatasi sumber daya koneksi dan pesan. Lakukan rotasi kunci dengan periode tumpang tindih (overlap) dan pantau kegagalan dekapsulasi, penolakan replay, latensi, serta distribusi panjang pesan; jangan menampilkan OHTTP sebagai perlindungan terhadap kolusi atau analisis lalu lintas.
Pembahasan mendalam langkah demi langkah
1. Tentukan empat tanggung jawab
Client mengetahui sumber daya target dan kunci publik gateway. Relay mengetahui koneksi jaringan klien tetapi tidak boleh membaca konten yang dienkapsulasi. Gateway mendekripsi dan mengirimkan HTTP biasa ke Target, yang melihat gateway sebagai sumbernya. Pisahkan deployment, log, dan izin akses sehingga satu pihak tidak dapat dengan mudah mengorelasikan identitas dan konten.
2. Temukan dan validasi konfigurasi kunci
Klien memperoleh konfigurasi kunci gateway yang berisi pengidentifikasi kunci, algoritma HPKE, dan kunci publik. Konfigurasi ini memerlukan sumber terautentikasi, versi, dan waktu kedaluwarsa; tolak algoritma yang tidak didukung dan kunci yang sudah usang. Selama rotasi, publikasikan kunci lama dan baru secara bersamaan hingga cache klien dan jendela permintaan berakhir.
3. Enkapsulasi permintaan dan respons
Klien mengodekan permintaan HTTP biner dan mengenkapsulasinya dengan HPKE sebagai payload message/ohttp-req. Gateway mendekapsulasi dan memvalidasi metode, sumber daya target, ukuran, dan jenis konten. Gateway mengenkapsulasi respons sebagai message/ohttp-res. Relay tidak boleh mem-parsing HTTP internal atau merutekan berdasarkan status teks biasa.
Client -- TLS --> Relay -- opaque OHTTP --> Gateway -- HTTP --> Target
Client <-- opaque response -- Relay <-- OHTTP response -- Gateway4. Tangani autentikasi, replay, dan idempotensi
OHTTP menyembunyikan identitas jaringan; ini tidak mengautentikasi pengguna bisnis. Untuk penulisan, gunakan tanda tangan aplikasi, nonce sekali pakai, jendela waktu, atau kunci idempotensi. Gateway mempertahankan status deteksi replay minimal dan menolak pesan terenkapsulasi yang berulang. Batch telemetri dapat membawa ID peristiwa yang idempoten sehingga percobaan ulang tidak menyebabkan penghitungan ganda.
5. Tangani error dan pemetaan sumber daya
Jika dekapsulasi gagal, gateway mengembalikan error kunci atau enkapsulasi yang terstruktur tanpa mengekspos detail kunci privat. Error bisnis target dikirim kembali di dalam respons OHTTP. Pemetaan sumber daya relay-ke-gateway harus tetap dan dapat diverifikasi sehingga pesan tidak dapat mencapai target yang salah. Terapkan batas terpisah untuk timeout, ukuran, dan beban berlebih di setiap lapisan.
6. Evaluasi kebocoran privasi dan analisis lalu lintas
Enkripsi tidak menghentikan relay untuk melihat IP klien, waktu, dan panjang pesan, atau gateway melihat frekuensi permintaan dan bidang aplikasi yang didekripsi. Padding, batching, batas laju, dan log yang terpisah dapat mengurangi korelasi dengan kompromi latensi dan biaya. Jangan mengklaim bahwa OHTTP mengalahkan kolusi relay/gateway.
7. Canary, pemantauan, dan fallback
Mulai dengan kelompok klien kecil dan sumber daya relay/gateway khusus. Lacak hit konfigurasi, keberhasilan dekapsulasi, penolakan replay, target 5xx, latensi p95, bucket ukuran pesan, dan tingkat fallback. Selama insiden, nonaktifkan OHTTP secara terbatas berdasarkan target atau versi klien; fallback ke HTTPS biasa memerlukan tinjauan privasi. Simpan ID konfigurasi, kelas error, dan hash permintaan, bukan bidang identitas internal.
Contoh jawaban berkualitas tinggi
Saya akan memisahkan klien, relay, gateway, dan target ke dalam empat domain tanggung jawab. Klien memperoleh dan memvalidasi konfigurasi kunci HPKE gateway, mengenkapsulasi HTTP biner, dan mengirimkannya ke relay. Relay meneruskan byte buram (opaque bytes). Gateway mendekapsulasi, memeriksa ukuran dan pemetaan sumber daya, serta memanggil target dengan identitasnya sendiri; respons dienkapsulasi dalam perjalanan kembali.
OHTTP tidak menyediakan autentikasi bisnis atau menggagalkan kolusi relay/gateway. Oleh karena itu, penulisan memerlukan tanda tangan aplikasi, nonce, atau kunci idempotensi, dengan pemeriksaan replay jendela waktu pada gateway. Rotasikan kunci dengan jendela tumpang tindih dan batasi koneksi relay serta sumber daya pesan. Terapkan canary untuk memantau kegagalan dekapsulasi, penolakan replay, latensi, distribusi ukuran, dan error bisnis; izinkan fallback ke HTTPS biasa hanya setelah tinjauan privasi eksplisit.
Kesalahan umum
- Memperlakukan relay sebagai proksi yang mendekripsi → batasan privasi hilang → biarkan relay hanya menangani koneksi luar dan pesan buram.
- Mengasumsikan OHTTP mengautentikasi pengguna → target tidak dapat mengidentifikasi entitas bisnis yang sah → tambahkan tanda tangan aplikasi atau token otorisasi.
- Mengabaikan panjang pesan dan waktu → analisis lalu lintas masih dapat mengorelasikan permintaan → gunakan padding dan batching sambil mengukur biaya latensi.
- Mencoba ulang penulisan tanpa idempotensi → telemetri dihitung ganda atau efek samping berulang → gunakan nonce, ID peristiwa, dan jendela replay.
- Berbagi log relay dan gateway yang dapat ditautkan → satu pihak dapat memulihkan identitas dan konten → pisahkan operator, bidang data, dan izin akses.
Pertanyaan lanjutan dan jawaban
Dapatkah OHTTP mencegah kolusi relay dan gateway?
Tidak. Protokol ini bergantung pada kepercayaan terbatas dan pemisahan operasional. Pihak yang berkolusi dapat mengorelasikan identitas koneksi dengan konten yang didekripsi, sehingga organisasi, log, dan kontrol akses harus tetap independen.
Bagaimana gateway mencegah replay?
Gunakan jendela waktu, nonce, ID peristiwa idempoten, atau tanda tangan aplikasi untuk penulisan; pertahankan status deteksi minimal dan tolak pesan terenkapsulasi yang berulang. TLS pada setiap koneksi saja tidak mencegah replay lintas-koneksi.
Mengapa pemetaan sumber daya diperlukan?
Relay harus meneruskan permintaan terenkapsulasi ke sumber daya gateway/target yang dituju. Pemetaan tetap membuat batasan kunci, kebijakan, batas laju, dan audit dapat diverifikasi serta mencegah pengiriman ke gateway yang tidak kompatibel.
Bagaimana cara merotasi kunci publik gateway?
Publikasikan konfigurasi baru berversi dengan masa kedaluwarsa sambil mempertahankan kunci lama selama jendela cache, batching, dan percobaan ulang. Amati hit dan kegagalan dekapsulasi berdasarkan ID kunci, lalu hentikan kunci privat lama.
Apakah OHTTP cocok untuk penulisan bernilai tinggi?
Hanya dengan kehati-hatian. Ini menyembunyikan identitas jaringan tetapi tidak menggantikan autentikasi, otorisasi, idempotensi, atau audit. Buktikan entitas aplikasi dan batasan replay sebelum menerima kompromi latensi dan privasinya.
Apa yang harus dicatat oleh pemantauan?
Catat ID konfigurasi, sumber daya relay/gateway, kelas error, bucket ukuran permintaan, penolakan replay, dan latensi end-to-end. Jangan mencatat domain internal, pengidentifikasi pengguna, atau konten mentah terenkapsulasi secara default.