Oblivious HTTP (OHTTP): Cara Kerja dan Batas Privasi Permintaan Web

Ketika aplikasi mengirim permintaan ke sebuah layanan internet, alamat IP, waktu akses, dan pola koneksi dapat memberi petunjuk tentang siapa penggunanya. HTTPS melindungi isi komunikasi dari penyadap jaringan, tetapi tidak otomatis menyembunyikan seluruh metadata dari setiap perantara. Oblivious HTTP (OHTTP) dirancang untuk mengurangi hubungan langsung antara identitas jaringan pengguna dan isi permintaan tertentu dengan membagi peran ke beberapa pihak.

OHTTP bukan alat anonimitas universal dan bukan pengganti HTTPS. Teknologi ini berguna ketika aplikasi ingin mengirim permintaan secara lebih privat, misalnya untuk pengukuran, telemetri, atau pengambilan data yang tidak perlu mengungkap alamat IP pengguna kepada layanan tujuan. Memahami batasnya penting sebelum OHTTP diterapkan pada sistem produksi.

Apa Itu Oblivious HTTP?

Oblivious HTTP adalah protokol yang memungkinkan klien mengirim pesan HTTP melalui perantara tanpa membuat satu pihak perantara memperoleh seluruh informasi sekaligus. Spesifikasi protokol ini diterbitkan sebagai RFC 9458. Konsep utamanya adalah memisahkan pihak yang mengetahui alamat jaringan klien dari pihak yang dapat membuka isi permintaan.

Dalam penerapan umum, terdapat tiga peran:

• Klien: aplikasi atau browser yang membuat permintaan dan mengenkripsinya untuk gateway yang dituju.
• Relay: menerima pesan terenkripsi dari klien dan meneruskannya ke gateway. Relay dapat melihat koneksi masuk dan alamat IP klien, tetapi tidak semestinya dapat membaca isi permintaan OHTTP.
• Gateway: membuka pesan OHTTP lalu meneruskan permintaan ke layanan tujuan. Gateway dapat memproses isi permintaan, tetapi seharusnya tidak memperoleh alamat IP asli klien dari pesan yang diteruskan relay.

Pemisahan ini efektif jika relay dan gateway tidak berkolusi serta dikelola dengan praktik privasi yang baik. Jika satu organisasi mengendalikan keduanya, atau keduanya berbagi log yang sangat rinci, manfaat pemisahan informasi dapat berkurang.

Bagaimana Alur OHTTP Bekerja?

1. Klien menyiapkan pesan. Aplikasi membentuk permintaan HTTP dan mengenkripsinya menggunakan konfigurasi kunci publik gateway yang sesuai dengan protokol OHTTP.
2. Relay menerima pesan. Klien mengirim pesan terenkripsi ke relay melalui koneksi aman. Relay melihat informasi koneksi yang diperlukan untuk menerima permintaan, tetapi tidak dapat membaca isi pesan yang dilindungi enkripsi OHTTP.
3. Gateway membuka permintaan. Relay meneruskan pesan ke gateway. Gateway mendekripsi dan memvalidasi pesan, kemudian meneruskan permintaan ke layanan tujuan sesuai kebijakan implementasinya.
4. Respons dikembalikan. Gateway melindungi respons dengan mekanisme OHTTP yang sesuai, lalu mengirimkannya kembali melalui relay ke klien. Klien membuka respons tersebut.

Dengan demikian, relay tidak perlu mengetahui isi permintaan, sedangkan gateway tidak perlu menerima koneksi langsung dari alamat IP pengguna. Namun, detail yang terlihat tetap bergantung pada konfigurasi, implementasi, dan informasi tambahan yang dicatat oleh masing-masing pihak.

Apa Bedanya dengan HTTPS, VPN, dan Proxy?

HTTPS mengenkripsi komunikasi antara klien dan server, tetapi alamat IP klien masih terlihat oleh server yang menerima koneksi. HTTPS tetap dibutuhkan saat OHTTP digunakan; keduanya menyelesaikan persoalan yang berbeda.

VPN biasanya mengalihkan banyak lalu lintas perangkat melalui penyedia VPN. Penyedia tersebut dapat mengetahui alamat IP pelanggan dan metadata koneksi, meskipun isi lalu lintas HTTPS tetap terenkripsi. OHTTP lebih terarah: aplikasi menggunakannya untuk jenis permintaan tertentu, dan model privasinya bergantung pada pemisahan relay serta gateway.

Proxy biasa dapat meneruskan permintaan, tetapi sering kali memiliki akses ke metadata klien dan isi permintaan, tergantung pada enkripsi dan konfigurasi. OHTTP menambahkan perlindungan kriptografis agar relay tidak membaca pesan yang ditujukan kepada gateway. OHTTP bukan pengganti semua proxy dan tidak otomatis menyembunyikan setiap aktivitas web.

Kapan OHTTP Berguna?

OHTTP dapat dipertimbangkan untuk telemetri yang meminimalkan data identitas, pengukuran iklan yang menjaga privasi, layanan pengambilan konfigurasi, atau aplikasi yang perlu meminta data dari server tanpa mengungkap alamat IP klien langsung kepada server tersebut. Kesesuaian penggunaannya harus dinilai berdasarkan kebutuhan produk dan data yang diproses.

Jika layanan memang perlu mengetahui akun pengguna untuk menampilkan data personal, OHTTP tidak menghapus kebutuhan autentikasi. Identitas yang dikirim di dalam isi permintaan tetap dapat mengungkap pengguna kepada gateway atau layanan tujuan. Karena itu, hindari memasukkan pengenal akun, token, atau atribut unik jika tidak benar-benar diperlukan.

Batas Privasi dan Risiko yang Perlu Dipahami

• Kolusi relay dan gateway: kedua pihak yang menggabungkan log dapat menghubungkan sumber permintaan dengan aktivitas tertentu.
• Analisis waktu dan ukuran: pola waktu, volume, serta ukuran pesan dapat membantu korelasi lalu lintas, terutama jika jumlah pengguna kecil.
• Log berlebihan: alamat IP di relay atau parameter sensitif di gateway dapat tersimpan lebih lama dari yang dibutuhkan.
• Metadata di luar OHTTP: DNS, koneksi lain, cookie, sidik jari perangkat, dan permintaan aplikasi yang tidak melewati OHTTP tetap dapat memberi petunjuk identitas.
• Keamanan implementasi: kesalahan pengelolaan kunci, validasi pesan, atau konfigurasi transportasi dapat melemahkan perlindungan.

OHTTP juga tidak membuat konten yang berbahaya menjadi aman. Gateway tetap perlu memvalidasi permintaan, membatasi ukuran payload, menerapkan rate limiting, dan mencegah penyalahgunaan sumber daya. Keamanan transportasi dan kontrol akses harus dirancang terpisah dari tujuan privasi.

Checklist Penerapan yang Lebih Aman

1. Tentukan ancaman yang ingin dikurangi. Jelaskan apakah tujuannya menyembunyikan alamat IP dari layanan tujuan, membatasi pengumpulan data, atau mengurangi kemampuan korelasi antarpermintaan.
2. Pisahkan pengelolaan relay dan gateway. Bila memungkinkan, gunakan batas administratif yang jelas, minimalkan pertukaran log, dan tetapkan tanggung jawab privasi untuk masing-masing pihak.
3. Kelola kunci dan rotasinya. Gunakan implementasi OHTTP yang teruji, lindungi kunci privat gateway, siapkan rotasi, dan rencanakan perubahan konfigurasi tanpa memutus klien secara mendadak.
4. Minimalkan data dan retensi. Jangan mencatat payload sensitif. Batasi masa simpan log, kontrol akses operator, serta dokumentasikan data apa yang terlihat oleh relay dan gateway.
5. Uji kegagalan dan penyalahgunaan. Uji pesan rusak, lonjakan trafik, gateway tidak tersedia, respons berukuran besar, dan penanganan error. Pastikan pesan gagal tidak membocorkan isi melalui log atau pesan kesalahan.

Untuk konteks yang lebih luas, prinsip pengurangan data juga relevan saat merancang analitik website yang lebih privat. Pilih arsitektur berdasarkan model ancaman dan ukur data yang benar-benar dikumpulkan, bukan sekadar mengandalkan nama protokol.

Kesimpulan

Oblivious HTTP menawarkan cara memisahkan informasi tentang sumber koneksi dari isi permintaan HTTP dengan bantuan relay dan gateway. Pendekatan ini dapat meningkatkan privasi untuk alur aplikasi tertentu, tetapi manfaatnya bergantung pada independensi pihak yang terlibat, minimisasi log, pengelolaan kunci, dan rancangan permintaan.

Gunakan OHTTP ketika ada kebutuhan privasi yang jelas dan protokol ini cocok dengan alur aplikasi. Tetap gunakan HTTPS, hindari pengenal yang tidak perlu, serta lakukan penilaian risiko menyeluruh. OHTTP adalah salah satu lapisan perlindungan privasi—bukan jaminan anonimitas total.