Cloudflare OHTTP Gateway Masuk Beta: Sembunyikan IP Pengguna dengan Model Double-Blind

Cloudflare membuka beta tertutup untuk layanan Cloudflare OHTTP Gateway pada awal Oktober 2026, bertepatan dengan rangkaian Birthday Week mereka. Layanan ini memakai Oblivious HTTP, standar IETF yang dijelaskan dalam RFC 9458, untuk membuat backend aplikasi bisa menerima permintaan HTTP tanpa melihat alamat IP pengguna. Model privasinya disebut double-blind: relay hanya melihat identitas klien, sementara gateway dan server aplikasi hanya melihat isi permintaan, sehingga tidak ada satu pihak pun yang melihat keduanya sekaligus. Bagi tim yang menyimpan data sensitif, ini arsitektur yang layak dipahami sebelum dipakai.

TL;DR

• Cloudflare membuka beta tertutup OHTTP Gateway pada Oktober 2026.
• Oblivious HTTP adalah standar IETF yang dijelaskan di RFC 9458.
• Dua hop terpisah, relay dan gateway, menciptakan model double-blind.
• Privacy Gateway lama diganti nama menjadi Cloudflare OHTTP Relay.
• Gateway menolak mendekripsi permintaan dari Worker atau host yang diproksikan Cloudflare.

Apa Itu Oblivious HTTP dan Kenapa Penting?

Oblivious HTTP atau OHTTP adalah protokol untuk meneruskan pesan HTTP terenkripsi, yang memungkinkan klien mengirim banyak permintaan ke server asal tanpa server itu bisa menautkan permintaan tersebut ke klien atau mengenali bahwa permintaan itu berasal dari klien yang sama. Definisi ini diambil langsung dari RFC 9458 yang diterbitkan IETF. Intinya, OHTTP memisahkan identitas pengirim dari isi permintaan, sesuatu yang tidak bisa dilakukan oleh proxy biasa karena proxy standar tetap melihat keduanya.

Masalah yang diselesaikan terasa sehari-hari. Menurut pengumuman Cloudflare, pengguna saat ini menanggung terlalu banyak beban privasi: untuk menghindari pelacak pihak ketiga atau iklan bertarget, mereka disuruh memakai VPN, menonaktifkan cookie, atau memasang pemblokir iklan. Sementara itu, pertukaran klien-server yang biasa meninggalkan jejak data seperti alamat IP atau sidik jari TLS. OHTTP mencoba mengurangi jejak itu di tingkat protokol, bukan di tingkat kebiasaan pengguna.

Bagaimana Cara Kerja Model Double-Blind?

Dalam OHTTP, permintaan melewati dua hop yang dioperasikan secara terpisah: relay dan gateway. Relay hanya meneruskan permintaan terenkripsi secara buta, dan tugasnya menyembunyikan identitas klien dari server aplikasi. Gateway melakukan kerja kriptografi: mendekapsulasi permintaan terenkripsi dan mengenkapsulasi respons, sehingga server aplikasi bisa menangani permintaan OHTTP seolah-olah itu HTTP biasa. Pemisahan kepercayaan antara relay dan gateway inilah yang membuat tidak ada satu pihak pun melihat identitas klien sekaligus isi permintaan.

Yang membedakan OHTTP dari proxy penerus biasa adalah enkripsi antara klien dan server aplikasi. Permintaan dan respons dikapsulkan memakai Hybrid Public Key Encryption atau HPKE, sehingga hanya klien dan server aplikasi yang bisa melihat teks asli, sementara relay hanya melihat sekumpulan ciphertext. Hasilnya adalah model yang disebut double-blind: relay melihat hanya identitas klien, gateway dan server aplikasi melihat hanya isi permintaan, dan tidak ada pihak yang melihat keduanya.

Apa Saja Opsi yang Tersedia untuk Pengguna?

Cloudflare menyediakan dua jalur yang perlu dipilih sesuai arsitektur. Pilihan pertama, memakai Cloudflare OHTTP Relay lalu menjalankan gateway sendiri, paling cocok kalau server aplikasi dihosting di luar Cloudflare dan kamu mampu mengoperasikan gateway sendiri. Pilihan kedua, memakai Cloudflare OHTTP Gateway dengan relay pihak ketiga, paling cocok kalau server aplikasi sudah berada di belakang Cloudflare, atau kalau kamu menerima permintaan OHTTP dari pihak ketiga, atau kalau kamu ingin gateway terkelola untuk menekan latensi dan beban operasional.

Perlu dicatat bahwa nama produk lamanya berubah. Relay yang dulu bernama Privacy Gateway kini disebut Cloudflare OHTTP Relay, agar lebih jelas membedakannya dari gateway. Perubahan nama ini penting karena keduanya punya peran berbeda, dan mencampuradukkannya bisa membuat desain privasi menjadi salah. Sebelumnya, pelanggan yang melindungi server di belakang Cloudflare tidak bisa memakai relay Cloudflare, karena Cloudflare akan melihat metadata klien sekaligus isi permintaan yang didekripsi, yang justru merusak model privasi OHTTP.

Bagaimana Perbandingan Relay dan Gateway?

Tabel berikut merangkum perbedaan peran keduanya agar tidak tertukar saat merancang arsitektur.

Aspek	OHTTP Relay	OHTTP Gateway
Yang dilihat	Identitas klien	Isi permintaan terdekripsi
Tugas utama	Meneruskan permintaan terenkripsi	Mendekapsulasi dan mengenkapsulasi
Operasi kriptografi	Tidak ada	Menangani HPKE
Cocok untuk	Server di luar Cloudflare	Server di belakang Cloudflare
Nama lama	Privacy Gateway	Produk baru

Siapa yang Sudah Memakai OHTTP?

Ada beberapa contoh nyata yang disebut Cloudflare. Flo Health memakai OHTTP untuk fitur Anonymous Mode di aplikasinya, sehingga data kesehatan sensitif tidak bisa dikaitkan dengan identitas pengguna. Apple memakai OHTTP di Private Cloud Compute untuk memisahkan permintaan inferensi AI dari identitas pengguna. Selain itu, Apple menyediakan LiveCallerID SDK yang memakai OHTTP, dan Cloudflare menyebut gateway mereka cocok untuk menerima permintaan dari relay pihak ketiga seperti kasus tersebut.

Pola yang muncul dari contoh-contoh itu konsisten: OHTTP dipakai ketika isi permintaan bersifat sensitif dan kaitannya dengan identitas pengguna harus diputus. Ini bukan alat untuk menyembunyikan diri dari penyedia layanan, melainkan untuk memastikan tidak ada satu titik pun dalam rantai yang bisa melihat gambaran lengkap. Bagi aplikasi kesehatan, keuangan, atau apa pun yang menyentuh data pribadi, model seperti ini mengurangi permukaan risiko secara struktural.

Bagaimana Cara Mengaktifkan Gateway?

Menurut pengumuman Cloudflare, gateway dirancang agar mudah dinyalakan. Dengan beberapa klik, kamu bisa mengaktifkan Gateway pada zona dan mulai mengirim OHTTP ke alamat well-known ohttp-gateway pada domainmu. Layanan ini menyesuaikan kapasitas secara otomatis, jadi kamu tidak perlu mengurus penyediaan sumber daya. Karena gateway berjalan di setiap server di jaringan edge global Cloudflare, latensi hop dari relay ke gateway bisa ditekan, dan kalau kamu memakai CDN mereka, permintaan bisa didekripsi lalu diselesaikan di mesin yang sama.

Ada beberapa pengamanan yang menyertainya. Gateway mengikatkan diri ke zona, sehingga klien yang mengirim ke satu subdomain tidak bisa memakai zona itu untuk menargetkan domain lain. Gateway juga perlu mengautentikasi relay, karena secara desain gateway tahu sangat sedikit tentang klien, sehingga kepercayaan ditempatkan pada relay untuk mengautentikasi klien dan meneruskan lalu lintas secara bertanggung jawab. Yang paling penting, gateway akan menolak mendekripsi permintaan yang dikirim dari Worker Cloudflare atau host yang diproksikan di Cloudflare, supaya pemisahan kepercayaan tetap terjaga dan Cloudflare tidak pernah melihat identitas klien sekaligus isi permintaan.

Apakah OHTTP Sulit Diterapkan?

Tidak terlalu sulit untuk sisi klien, tetapi menuntut perhatian pada sisi operasional. Cloudflare menyebut bahwa membangun dan mengoperasikan gateway OHTTP yang aman dan cepat pada skala besar bukan pekerjaan sepele, dan itulah alasan mereka menawarkan gateway terkelola. Setiap arsitektur proksi menambah latensi karena permintaan harus menempuh satu atau dua hop tambahan, lalu ditambah biaya mendekripsi permintaan dan mengenkripsi respons. Mengoperasikan gateway sendiri berarti menanggung kedua biaya itu plus tanggung jawab keamanannya.

Kalau kamu menerima permintaan OHTTP dari relay pihak ketiga, gateway terkelola menghilangkan beban itu. Kalau server aplikasimu berada di luar Cloudflare dan kamu ingin mempertahankan kendali penuh, menjalankan gateway sendiri dengan relay Cloudflare tetap pilihan yang sah. Yang penting, jangan mencampur keduanya secara asal, karena model privasinya bergantung pada pemisahan peran yang jelas dan terdokumentasi.

Apa Risiko yang Perlu Diperhatikan?

Risiko utamanya adalah merusak pemisahan kepercayaan tanpa sadar. Kalau relay dan gateway dioperasikan pihak yang sama, pihak itu bisa melihat identitas klien sekaligus isi permintaan, dan seluruh manfaat OHTTP hilang. Cloudflare mengantisipasi kesalahan ini dengan membuat gateway menolak mendekripsi permintaan dari Worker Cloudflare atau host yang diproksikan di Cloudflare, sehingga konfigurasi yang keliru tidak diam-diam membatalkan jaminan privasi.

Risiko kedua adalah latensi. Karena permintaan menempuh hop tambahan, aplikasi yang sangat sensitif terhadap waktu perlu diuji dengan cermat. Menjalankan gateway di jaringan edge yang tersebar membantu menekan hop relay ke gateway, tetapi perjalanan dari klien ke relay tetap menambah waktu. Mengukur sebelum dan sesudah penerapan adalah cara paling jujur untuk mengetahui dampaknya pada pengalaman pengguna.

Bagaimana OHTTP Dibandingkan dengan Proxy Biasa?

Proxy biasa meneruskan permintaan dan biasanya bisa melihat identitas klien maupun isi permintaan dalam bentuk teks asli. OHTTP memisahkan keduanya: relay melihat identitas tetapi hanya ciphertext, sedangkan gateway dan server aplikasi melihat isi tetapi bukan identitas. Perbedaan ini bukan sekadar penyempurnaan, melainkan perubahan struktural pada siapa yang bisa mengetahui apa. Itulah alasan OHTTP dipakai untuk kasus sensitif seperti data kesehatan dan inferensi AI, di mana keterkaitan antara identitas dan isi justru menjadi sumber risiko terbesar.

Apakah OHTTP Menggantikan VPN?

Tidak. Keduanya menyelesaikan masalah yang berbeda. VPN menyembunyikan lalu lintas secara menyeluruh dan mengalihkan tanggung jawab kepercayaan ke penyedia VPN, sedangkan OHTTP memisahkan identitas klien dari isi permintaan pada tingkat protokol dengan dua hop yang dioperasikan pihak berbeda. OHTTP tidak menyembunyikan fakta bahwa kamu mengirim permintaan, tetapi memastikan tidak ada satu titik pun yang bisa menghubungkan permintaan itu dengan identitasmu. Untuk aplikasi yang perlu menerima data sensitif tanpa menyimpannya bersama identitas, pendekatan ini lebih tepat daripada meminta pengguna memasang alat tambahan.

Karena itu, nilai OHTTP paling terasa ketika diintegrasikan ke dalam produk, bukan ditambahkan sebagai lapisan terpisah oleh pengguna. Pengguna tidak perlu tahu apa pun; yang berubah adalah apa yang bisa dilihat oleh backend. Inilah yang membedakannya dari sekadar imbauan agar pengguna melindungi diri sendiri, dan alasan mengapa pendekatan ini lebih mungkin bertahan dalam jangka panjang.

FAQ

Apa perbedaan OHTTP Relay dan OHTTP Gateway?

Relay meneruskan permintaan terenkripsi dan menyembunyikan identitas klien, sedangkan gateway menangani kerja kriptografi untuk mendekapsulasi permintaan dan mengenkapsulasi respons bagi server aplikasi.

Apakah Cloudflare bisa melihat isi permintaan?

Dalam model yang benar, tidak. Pemisahan kepercayaan memastikan relay hanya melihat identitas klien dan gateway hanya melihat isi, sehingga tidak ada satu pihak pun yang melihat keduanya sekaligus.

Apakah layanan ini sudah tersedia umum?

Belum. Cloudflare membuka beta tertutup untuk OHTTP Gateway yang bisa dipakai sendiri, dan pendaftaran dilakukan lewat daftar tunggu yang disediakan pada pengumuman resminya.

Kenapa gateway menolak permintaan dari Worker Cloudflare?

Karena kalau relay dan gateway sama-sama dioperasikan Cloudflare, model privasi OHTTP rusak. Penolakan itu menjaga pemisahan kepercayaan tetap utuh secara struktural.

Apakah OHTTP sama dengan VPN?

Bukan. VPN menyembunyikan lalu lintas secara menyeluruh, sedangkan OHTTP memisahkan identitas klien dari isi permintaan pada tingkat protokol, dengan dua hop yang dioperasikan pihak berbeda.

Sumber utama: pengumuman Cloudflare OHTTP Gateway, spesifikasi RFC 9458 tentang Oblivious HTTP, dan dokumentasi Cloudflare Privacy Gateway.