Apa Itu Otentikasi Proksi? Penjelasan Sederhana

Kami menjual proxy di Geonode, jadi ini adalah penjelasan mengenai produk kami sendiri. Rekomendasi yang tidak memerlukan biaya apa pun bagi kami dan sangat membantu kebanyakan orang: jika alamat sumber Anda stabil, gunakan daftar putih IP daripada nama pengguna dan kata sandi. Hal ini sepenuhnya menghilangkan kredensial dari perintah, skrip, variabel lingkungan, dan hasil terminal yang Anda tempelkan — dan tidak ada yang bisa bocor jika tidak ada yang dikirim. Sebagian besar penyedia layanan menawarkannya, termasuk kami, namun fitur ini kurang dimanfaatkan karena panduan pengaturan biasanya menampilkan metode nama pengguna dan kata sandi terlebih dahulu. Sisa artikel ini membahas keduanya, serta alasan mengapa otentikasi berbasis nama pengguna dan kata sandi (SOCKS5) memerlukan kehati-hatian yang lebih besar daripada yang biasanya diberikan.

Dua Metode yang Ditawarkan Penyedia Layanan

Nama pengguna dan kata sandi. Anda akan diberikan kredensial dan mengirimkannya bersama setiap permintaan. Metode ini berfungsi dari alamat mana pun, sehingga menjadi satu-satunya pilihan saat alamat Anda berubah — baik itu laptop, koneksi seluler, kontainer dengan alamat dinamis, atau sekelompok pekerja yang tersebar.

Daftar putih IP. Anda mendaftarkan alamat-alamat asal permintaan Anda, dan proxy akan menerima semua permintaan dari alamat-alamat tersebut tanpa memerlukan kredensial. Metode ini hanya berfungsi dari alamat-alamat tersebut, dan justru sifat inilah yang menjadikannya aman.

Sebagian besar penyedia layanan komersial mendukung kedua metode tersebut, dan banyak di antaranya mengizinkan penggunaan keduanya secara bersamaan. Perbandingan kelebihannya cukup jelas:

Untuk scraper yang berjalan di server dengan alamat statis, daftar putih jelas lebih baik. Untuk apa pun yang bersifat mobile atau sementara, kredensial adalah satu-satunya opsi yang dapat diterapkan. Untuk CI runner, hal ini sepenuhnya bergantung pada apakah platform Anda memberikan alamat keluar yang dapat diprediksi, dan banyak yang tidak.

Cara Kerja Otentikasi Proksi HTTP

Mekanismenya berupa tantangan dan respons, sebagaimana didefinisikan dalam RFC 9110.

Anda mengirimkan permintaan. Jika proxy memerlukan otentikasi dan Anda tidak menyertakannya, proxy akan merespons dengan kode status 407 Proxy Authentication Required

dan menyertakan tantangan. Spesifikasi ini tegas mengenai hal ini: "Sebuah proxy HARUS mengirimkan setidaknya satu bidang header Proxy-Authenticate dalam setiap respons 407 (Proxy Authentication Required) yang dihasilkannya."

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="proxy.example.com"

Anda mengirim ulang permintaan dengan kredensial dalam header ``Proxy-Authorization`

`, yang menurut RFC memungkinkan "klien untuk mengidentifikasi dirinya (atau penggunanya) kepada proxy yang memerlukan otentikasi".

Proxy-Authorization: Basic dXNlcjpwYXNz

Ada dua sifat yang membedakan hal ini dari otentikasi web biasa, dan keduanya berasal langsung dari spesifikasi.

Tantangan bersifat spesifik per lompatan. "Tidak seperti WWW-Authenticate, bidang header Proxy-Authenticate hanya berlaku untuk klien keluar berikutnya dalam rantai respons. Hal ini karena hanya klien yang memilih proxy tertentu yang kemungkinan besar memiliki kredensial yang diperlukan untuk otentikasi."

Kredensial tersebut digunakan, bukan diteruskan. "Ketika beberapa proxy digunakan dalam sebuah rantai, bidang header Proxy-Authorization digunakan oleh proxy masuk pertama yang mengharapkan untuk menerima kredensial." Sebuah proxy mungkin meneruskannya ke depan jika para proxy bekerja sama dengan cara tersebut, tetapi secara default kredensial Anda berhenti di hop pertama yang membutuhkannya.

RFC tersebut juga mencatat konsekuensi untuk rantai di dalam satu organisasi: ketika beberapa proxy dalam domain administratif yang sama mengeluarkan tantangan yang sama, "hal ini akan tampak seolah-olah Proxy-Authenticate diteruskan karena setiap proxy akan mengirimkan rangkaian tantangan yang sama."

407 versus 401: Perbedaan yang Penting

Hal paling berguna dalam artikel ini bagi siapa pun yang sedang melakukan debugging.

Kode berbeda, header berbeda, kredensial berbeda, solusi berbeda.

Kode 407 berarti Anda tidak pernah mencapai server tujuan. Proksi yang menghentikan Anda. Kredensial tujuan Anda tidak relevan, dan seberapa pun Anda menyesuaikannya, hal itu tidak akan membantu.

Kode 401 berarti proxy berfungsi dan tujuan meminta kredensial.

Keduanya dapat muncul bersamaan dalam satu konfigurasi, karena mungkin ada dua set kredensial yang independen yang terlibat. Dalam curl:

curl -x http://proxy.example.com:9000 \
     --proxy-user proxyuser:proxypass \
     -u apiuser:apipass \
     https://api.example.com/private

--proxy-user untuk proxy, -u untuk target. Menggabungkannya justru akan menimbulkan kebingungan yang ingin dicegah oleh bagian ini.

Untuk mengetahui hop mana yang menolak Anda tanpa perlu menebak:

curl -sS -o /dev/null -x "$PROXY" \
  -w 'connect=%{http_connect} status=%{response_code}\n' \
  https://example.com

connect=407 berarti proxy menolak Anda dan Anda tidak pernah mencapai target. connect=200 status=401 berarti proxy berfungsi dan target meminta kredensial. Dua masalah berbeda, dua solusi berbeda, satu perintah untuk membedakannya.

Otentikasi SOCKS5 Berbeda, dan Lebih Lemah

Perlu diketahui karena perbedaan ini merupakan pertimbangan keamanan yang nyata dan jarang dibahas.

SOCKS5 tidak menggunakan header HTTP. Otentikasi terjadi selama proses pembentukan koneksi, dalam subnegosiasi yang didefinisikan oleh RFC 1929. Klien mengirimkan struktur biner kecil yang berisi byte versi, panjang nama pengguna, nama pengguna, panjang kata sandi, dan kata sandi, sedangkan server membalas dengan byte status di mana X'00' menandakan keberhasilan. Jika server mengembalikan status kegagalan, server "HARUS menutup koneksi".

Catatan keamanan dalam RFC tersebut singkat dan harus dibaca dengan cermat:

Karena permintaan tersebut membawa kata sandi dalam teks biasa, subnegosiasi ini tidak direkomendasikan untuk lingkungan di mana "sniffing" mungkin terjadi dan praktis dilakukan.

Teks biasa, bukan base64, bukan hash. Otentikasi HTTP Basic setidaknya dikodekan dengan base64 — mudah dibalik, tetapi tidak dapat dibaca secara harfiah dalam tangkapan paket. Otentikasi SOCKS5 username/password mengirimkan kata sandi melalui jaringan sebagai byte.

Implikasi praktisnya:

Pada jaringan yang tidak tepercaya, pilihlah proxy HTTP melalui TLS, atau daftar putih (allowlist). Kredensial lebih terekspos dengan SOCKS5 dibandingkan dengan HTTP Basic, dan perbedaan ini penting pada jaringan bersama atau yang berisiko.

Gantilah kredensial SOCKS lebih sering daripada kredensial HTTP, karena risiko paparan lebih tinggi.

Perhatikan bahwa hal ini hanya berkaitan dengan otentikasi ke proxy. Lalu lintas Anda selanjutnya ke situs HTTPS tetap dilindungi oleh TLS. Yang dikirimkan tanpa perlindungan adalah kredensial itu sendiri.

Parameter dalam Nama Pengguna: Konvensi Penyedia Layanan

Sebuah pola yang membingungkan pemula dan tidak termasuk dalam standar apa pun.

Banyak penyedia layanan menyematkan konfigurasi di dalam string nama pengguna:

username-country-de-session-abc123:password

. Hal itu bukanlah fitur HTTP. Gerbang proxy mengurai bidang nama pengguna miliknya sendiri dan memperlakukan segmen tambahan tersebut sebagai instruksi — negara, pengenal sesi, atau pengaturan rotasi. Sintaksnya sangat bervariasi antar penyedia layanan.

Ada dua hal yang perlu diperhatikan.

Baca dokumentasi penyedia layanan Anda daripada menebak-nebak. Parameter yang salah format biasanya tidak menghasilkan kesalahan. Hal itu menghasilkan permintaan yang berfungsi namun dengan perilaku yang salah — sesi yang tidak bertahan lama, atau keluar di negara yang tidak Anda minta. Itu adalah kegagalan yang tidak terdeteksi, dan jenis kegagalan inilah yang bertahan paling lama.

Beberapa penyedia menggunakan port sebagai gantinya, dengan memetakan rentang port ke negara atau sesi, bukan dengan mengenkodekannya dalam nama pengguna. Tidak ada pendekatan yang lebih baik; Anda hanya perlu mengetahui pendekatan mana yang Anda gunakan.

Di Mana Kredensial Bocor

Empat tempat, semuanya umum, semuanya bisa dihindari.

Baris perintah. Terlihat dalam daftar proses oleh pengguna lain di mesin tersebut, dan disimpan dalam riwayat shell tanpa batas waktu. Manual curl sangat jelas mengenai hal ini: data sensitif "sebaiknya diambil dari berkas atau sejenisnya dan tidak pernah digunakan dalam teks biasa di baris perintah."

Variabel lingkungan. http_proxy=http://user:pass@host:9000 adalah cara konfigurasi standar, dan hal ini menempatkan kata sandi di lingkungan setiap proses anak, di /proc pada Linux, serta dalam setiap dump lingkungan.

Output terperinci. curl -v menyertakan header Proxy-Authorization, dan tangkapan layar terminal dapat tersebar ke tempat-tempat yang tidak diinginkan. Sunting informasi sensitif sebelum membagikannya.

Kontrol sumber. Kredensial yang dikodekan secara permanen dalam skrip dan telah dikomit tetap tersimpan dalam riwayat repositori setelah dihapus.

Langkah mitigasi, berdasarkan tingkat efektivitas: gunakan daftar putih IP dan jangan simpan kredensial sama sekali; simpan kredensial dalam berkas dengan izin terbatas seperti ~/.netrc dengan chmod 600; baca kredensial dari pengelola rahasia saat runtime; dan setidaknya hindari penyimpanan kredensial dalam riwayat shell dengan read -rs.

Satu detail pengkodean yang sering menimbulkan kebingungan: jika kata sandi Anda mengandung @, :, atau /, kata sandi tersebut harus dikodekan dengan tanda persen (percent-encoded) sebelum dimasukkan ke dalam URL proxy, atau parser akan memisahkannya di tempat yang salah dan Anda akan mendapatkan kode status 407 meskipun kredensial yang digunakan benar.

Mengonfigurasinya di Alat-Alat Umum

curl:

curl -x http://proxy.example.com:9000 --proxy-user user:pass https://example.com

wget — perhatikan bahwa alat ini tidak memiliki opsi ``--proxy`

, sehingga proxy diambil dari variabel lingkungan atau berkas ``.wgetrc

`:

wget --proxy-user=user --proxy-password=pass https://example.com

Lebih baik lagi, gunakan ``~/.wgetrc`

dengan opsi ``chmod 600

`:

http_proxy = http://proxy.example.com:9000/
proxy_user = user
proxy_password = pass

Python requests:

proxies = {"http": "http://user:pass@proxy.example.com:9000",
           "https": "http://user:pass@proxy.example.com:9000"}
requests.get("https://example.com", proxies=proxies)

Playwright:

const context = await browser.newContext({
  proxy: { server: 'http://proxy.example.com:9000', username: 'u', password: 'p' },
});

Perhatikan bahwa Playwright mengambil kredensial sebagai bidang terpisah, bukan dalam URL, sehingga masalah pengkodean persen dapat dihindari sepenuhnya.

Variabel lingkungan, yang didukung oleh banyak alat:

export http_proxy=http://user:pass@proxy.example.com:9000
export https_proxy=http://user:pass@proxy.example.com:9000
export no_proxy=localhost,127.0.0.1,.internal

Gunakan huruf kecil. Penggunaan huruf besar HTTP_PROXY

memiliki risiko yang telah didokumentasikan dalam lingkungan CGI, di mana header permintaan diubah menjadi variabel lingkungan huruf besar dan klien yang mendukungnya dapat dimanipulasi oleh header Proxy:

yang disediakan oleh penyerang.

Pemecahan Masalah

407 meskipun kredensial yang Anda gunakan diyakini sudah benar. Periksa apakah ada karakter khusus dalam kata sandi yang memerlukan pengkodean persen. Periksa apakah alamat IP Anda termasuk dalam daftar putih yang masa berlakunya telah habis. Pastikan alat tersebut benar-benar mengirimkan kredensial — curl -v ... 2>&1 | grep -i proxy-auth akan menunjukkannya kepada Anda.

Kode 407 yang muncul sesekali. Biasanya terjadi pada konfigurasi terdistribusi di mana beberapa worker memiliki alamat keluar yang berbeda dari yang ada di daftar putih Anda, atau pada gateway yang berganti-ganti di mana hanya beberapa titik akhir yang memerlukan otentikasi.

Berfungsi dengan curl, tetapi gagal di aplikasi Anda. Pustaka tersebut mungkin tidak mendukung otentikasi proxy untuk HTTPS, atau mungkin tidak menerapkan proxy sama sekali. Periksa apakah permintaan Anda benar-benar melewati proxy — layanan yang menampilkan alamat Anda adalah cara pengujian tercepat.

Berfungsi untuk HTTP, tetapi gagal untuk HTTPS. Untuk HTTPS, klien terlebih dahulu mengirimkan permintaan CONNECT, dan beberapa pustaka menangani otentikasi proxy untuk terowongan tersebut secara berbeda atau bahkan tidak sama sekali.

Otentikasi berhasil, namun permintaan tetap gagal. Artinya, ini bukanlah masalah otentikasi. Kode status 403 setelah permintaan CONNECT berhasil berasal dari server tujuan, bukan dari proxy.

Mengelola Kredensial di Seluruh Tim atau Armada

Begitu melibatkan lebih dari satu orang atau satu mesin, pengelolaan kredensial tidak lagi sekadar masalah kenyamanan, melainkan menjadi masalah operasional.

Berikan kredensial terpisah untuk setiap orang dan setiap layanan jika penyedia layanan Anda mengizinkannya. Akun bersama tunggal berarti Anda tidak dapat mengetahui pekerjaan siapa yang menyebabkan lonjakan penggunaan, tidak dapat mencabut akses seorang rekan kerja yang keluar tanpa mengganggu semua orang, dan tidak dapat mengidentifikasi sumber kebocoran. Sebaiknya tanyakan tentang sub-akun meskipun biayanya sedikit lebih mahal.

Jauhkan kredensial dari gambar kontainer dan kode sumber. Kata sandi yang tertanam dalam gambar kontainer akan tetap ada di setiap lapisan dan setiap salinan di registri, termasuk setelah Anda menghapusnya pada build berikutnya. Sisipkan kredensial saat runtime melalui mekanisme rahasia (secret) orkestrator, atau ambil dari pengelola rahasia (secret manager) saat startup.

Prioritaskan daftar putih (allowlist) untuk apa pun yang memiliki egress stabil. Server tetap, gerbang NAT dengan alamat statis, atau kluster Kubernetes di balik alamat IP egress yang diketahui, semuanya dapat menggunakan daftar putih dan sama sekali tidak menyimpan kredensial. Ini merupakan posisi yang jauh lebih baik daripada penanganan kredensial yang sehati-hati apa pun.

Rencanakan rotasi sebelum Anda membutuhkannya. Baca kredensial dari satu tempat — variabel lingkungan yang diisi oleh pengelola rahasia, atau berkas konfigurasi dengan izin terbatas — sehingga rotasi hanya memerlukan satu perubahan, bukan pencarian di seluruh basis kode. Saat Anda benar-benar perlu melakukan rotasi adalah saat Anda paling tidak ingin melakukan pencarian dengan grep.

Waspadai kegagalan commit yang tidak disengaja. Kredensial yang telah di-commit lalu dihapus tetap tersimpan dalam riwayat repositori, dan repositori publik berarti kredensial tersebut telah terkompromi terlepas seberapa cepat commit tersebut dibatalkan. Pemindaian repositori adalah asuransi yang murah, dan rotasi segera adalah satu-satunya solusi nyata.

Dan lacak penggunaan per kredensial. Jika penyedia layanan Anda melaporkan lalu lintas berdasarkan sub-akun, perubahan mendadak adalah sinyal paling awal yang akan Anda dapatkan bahwa kredensial telah dibagikan, bocor, atau sedang digunakan oleh tugas yang Anda lupakan. Itu juga merupakan cara termurah untuk mendeteksi jenis kesalahan yang paling mahal — loop tak terkendali yang menagih bandwidth yang tidak Anda rencanakan untuk dibeli.

Pertanyaan Lainnya

Apa itu kesalahan 407? Kode kesalahan

407 Proxy Authentication Required berarti proxy meminta kredensial dan tidak menerima kredensial yang valid. Kesalahan ini berasal dari proxy, bukan dari situs web, dan RFC 9110 mewajibkan proxy untuk menyertakan header Proxy-Authenticate yang menyebutkan skema yang diharapkan. Kredensial tujuan Anda tidak relevan dalam hal ini.

Apa perbedaan antara 401 dan 407?

Kode 401 berasal dari server tujuan dan menggunakan header WWW-Authenticate serta Authorization. Kode 407 berasal dari proxy dan menggunakan header Proxy-Authenticate serta Proxy-Authorization. Kode 407 berarti Anda sama sekali tidak pernah mencapai server tujuan.

Apakah daftar putih IP lebih baik daripada nama pengguna dan kata sandi?

Jika alamat sumber Anda stabil, ya. Tidak ada kredensial yang bocor, tidak ada yang muncul di riwayat shell Anda, dan tidak ada yang secara tidak sengaja disimpan ke repositori. Metode ini gagal jika alamat Anda berubah, itulah sebabnya kredensial tetap diperlukan untuk laptop, koneksi seluler, dan sebagian besar lingkungan CI.

Apakah kredensial proxy dienkripsi?

Otentikasi proxy HTTP Basic mengenkripsi kredensial tersebut dengan base64, yang dapat diuraikan tetapi tidak dapat dibaca secara langsung. Otentikasi nama pengguna/kata sandi SOCKS5 mengirimkannya dalam teks biasa — RFC 1929 secara eksplisit menyatakan hal ini dan menyarankan untuk tidak melakukannya "jika penyadapan dimungkinkan dan praktis dilakukan". Keduanya bukanlah enkripsi; transportasi lah yang melindungi Anda.

Mengapa kata sandi proxy saya yang mengandung karakter khusus gagal?

Karena @, :, dan / memiliki arti dalam URL. http://user:p@ss@host:9000 diparsing dengan cara yang tidak Anda maksudkan. Lakukan pengkodean persentase (percent-encode) pada karakter tersebut, atau gunakan klien yang menerima nama pengguna dan kata sandi sebagai bidang terpisah, bukan menyematkannya dalam URL.

Apa arti teks tambahan pada nama pengguna proxy saya?

Ini adalah konvensi penyedia untuk menyertakan opsi-opsi — seperti negara, pengenal sesi, atau pengaturan rotasi — ke dalam bidang nama pengguna. Hal ini bukan bagian dari standar apa pun, sintaksnya berbeda-beda tergantung penyedia, dan kesalahan biasanya menghasilkan permintaan yang berhasil namun berperilaku tidak sesuai, bukan menghasilkan kesalahan.

Bisakah saya menggunakan kredensial dan daftar putih (allowlist) secara bersamaan?

Pada banyak penyedia, ya, dan ini merupakan pengaturan yang masuk akal: daftar putih mencakup server tetap Anda tanpa memerlukan kredensial, sementara kredensial mencakup mesin pengembang dan apa pun dengan alamat yang berubah-ubah.

Apakah saya memerlukan kredensial terpisah untuk proxy dan situs web?

Jika keduanya memerlukan otentikasi, ya — keduanya merupakan mekanisme yang sepenuhnya terpisah dengan header yang berbeda. Dalam curl, formatnya adalah --proxy-user untuk proxy dan -u untuk target, dan jika dicampur, akan menghasilkan kode status 407 padahal Anda mengharapkan 401, atau sebaliknya.

Kesimpulan

Otentikasi proxy merupakan lapisan yang terpisah dari otentikasi situs web, dan protokol ini dirancang agar hal tersebut jelas. Kode status yang berbeda, header yang berbeda, kredensial yang berbeda. Begitu Anda memahami kode 407 sebagai "proxy menghentikan saya" dan 401 sebagai "situs tujuan meminta kredensial", berbagai jenis kegagalan yang membingungkan akan teratasi dengan sendirinya.

Mekanismenya sendiri sederhana: tantangan dalam Proxy-Authenticate, respons dalam Proxy-Authorization, yang diproses oleh hop pertama yang mengajukan permintaan. Hal yang perlu diingat adalah SOCKS5, di mana spesifikasinya secara jujur menyatakan bahwa kredensial dikirim dalam teks biasa — alasan untuk lebih memilih proxy HTTP atau daftar putih (allowlist) pada jaringan apa pun yang tidak Anda kendalikan.

Dan rekomendasi yang tidak memerlukan biaya apa pun bagi vendor: jika permintaan Anda berasal dari alamat yang stabil, gunakan daftar putih IP. Setiap kebocoran yang dijelaskan di sini — riwayat shell, daftar proses, dump lingkungan, kode sumber yang telah dikomit, hasil terminal yang disalin — bergantung pada adanya kredensial yang dapat bocor. Hilangkan kredensial tersebut, dan Anda menghilangkan kategori kebocoran tersebut.