Proksi HTTP dan HTTPS

Proksi HTTP menerima permintaan web dari browser atau aplikasi Anda dan terhubung ke tujuan atas nama Anda. Proksi dapat membawa trafik HTTP biasa dan, dengan dukungan metode CONNECT, trafik HTTPS terenkripsi. Proksi HTTPS menambahkan enkripsi pada koneksi antara aplikasi Anda dan proksi itu sendiri.

Ini adalah dua pilihan terpisah: cara aplikasi mencapai proksi dan cara aplikasi berkomunikasi dengan situs melalui proksi itu. Memahami keduanya membantu memilih pengaturan koneksi yang tepat. Pilihan umum antara protokol proksi dibahas dalam Proksi SOCKS dan HTTP.

Yang dilakukan proksi HTTP terhadap permintaan web

Misalkan skrip pemantauan meminta http://example.com/catalog. Alih-alih membuka koneksi ke situs, skrip terhubung ke proksi yang dikonfigurasi. Dengan HTTP/1.1, skrip mengirim URL tujuan lengkap dalam permintaannya agar proksi mengetahui server dan halaman yang harus dihubungi. Proksi meneruskan permintaan dan mengembalikan respons situs ke skrip.

Dalam mode ini, proksi memproses pesan HTTP. Proksi dapat membaca metode seperti GET atau POST, alamat yang diminta, header, dan data yang dikirimkan. Perangkat lunak yang dikonfigurasi untuk itu dapat menerapkan aturan akses, mencatat permintaan, atau menyimpan respons yang memenuhi syarat dalam cache. Cache adalah fungsi opsional yang mengikuti aturan penyimpanan respons; membeli akses proksi HTTP tidak berarti setiap halaman akan disimpan dalam cache.

Situs menerima koneksi jaringan dari IP keluar proksi. Istilah HTTP tidak menjelaskan asal IP atau berapa lama alokasinya bertahan. Protokol koneksi yang sama dapat ditawarkan dengan alamat pusat data, ISP, residensial, atau seluler, menggunakan IP tetap atau kumpulan berotasi.

Cara proksi HTTP membuka situs HTTPS

Situs HTTPS menggunakan TLS untuk melindungi pertukaran antara aplikasi dan situs. Untuk membawa pertukaran itu, proksi HTTP terlebih dahulu membuat terowongan. Untuk permintaan ke https://example.com/catalog, urutannya adalah:

1. Aplikasi terhubung ke proksi dan memintanya membuka terowongan ke example.com:443 menggunakan metode CONNECT. Permintaan menyebutkan host dan port tujuan, tanpa jalur halaman.
2. Proksi memeriksa apakah akses dan tujuan yang diminta diizinkan, termasuk autentikasi proksi yang diperlukan. Proksi membuka koneksi ke tujuan dan mengonfirmasi bahwa terowongan siap.
3. Aplikasi melakukan jabat tangan TLS dengan situs melalui terowongan dan memeriksa sertifikat situs.
4. Aplikasi mengirim permintaan webnya di dalam koneksi TLS tersebut. Proksi meneruskan bita terenkripsi ke kedua arah.

Proksi tidak perlu membaca halaman untuk mengirimkannya. Aplikasi dan situs tetap menjadi titik akhir koneksi TLS situs. CONNECT menyediakan terowongan; TLS menyediakan enkripsi dan melindungi pertukaran dari perubahan yang tidak terdeteksi.

Karena itu, proksi HTTP dapat membuka situs HTTPS meskipun alamat proksi dimulai dengan http://. Perlindungan HTTPS situs bekerja di dalam terowongan. Perlindungan itu tidak bergantung pada adanya TLS antara aplikasi dan proksi.

Tambahan yang diberikan proksi HTTPS

Dengan proksi HTTPS, aplikasi terlebih dahulu membentuk TLS dengan proksi dan memverifikasi sertifikat proksi. Aplikasi kemudian mengirim permintaan HTTP, atau permintaan CONNECT untuk terowongan, di dalam koneksi terlindungi itu. Pengamat jaringan antara aplikasi dan proksi tidak dapat membaca permintaan tersebut.

Untuk tujuan HTTPS, aplikasi mempertahankan dua koneksi TLS terpisah: satu dengan proksi dan satu dengan situs melalui terowongan. Proksi menghapus perlindungan luar yang ditujukan kepadanya, tetapi data situs di dalamnya tetap terenkripsi. Proksi meneruskan bita itu ke situs yang dapat mendekripsinya. Untuk tujuan HTTP, tidak ada koneksi TLS bagian dalam: hanya koneksi ke proksi yang terlindungi.

Perbandingan ini menjelaskan penerusan proksi biasa dengan pemeriksaan sertifikat aktif, tanpa inspeksi HTTPS atau VPN terpisah. Mengenkripsi koneksi ke proksi tidak meningkatkan situs HTTP menjadi HTTPS.

Yang dapat dilihat proksi dan situs

Untuk tujuan HTTPS, proksi penerus tidak dapat membaca jalur halaman, parameter kueri, cookie, data formulir, atau konten yang dikembalikan di dalam koneksi TLS. Proksi tetap mengetahui IP klien yang terhubung kepadanya, host dan port tujuan yang diminta dalam CONNECT, serta waktu dan volume trafik. TLS ke proksi menyembunyikan CONNECT dari pengamat pada bagian jaringan itu, tetapi tidak dari proksi yang harus menjalankannya.

Kredensial proksi dikirim terpisah dari login situs. Autentikasi proksi Basic mengodekan nama pengguna dan kata sandi menggunakan Base64, yang dapat didekode tanpa kunci rahasia. Pada koneksi proksi HTTP biasa, ini tidak melindunginya dari pengamat jaringan. Koneksi HTTPS situs dimulai di dalam terowongan dan tidak mencakup login proksi sebelumnya. TLS ke proksi melindungi login itu selama transmisi.

Di ujung lain, situs menerima trafik dari IP keluar dan membaca permintaan yang ditujukan kepadanya. Situs dapat mengenali akun, cookie sesi, atau informasi lain yang dikirim aplikasi. Memilih proksi HTTPS tidak menghapus pengenal itu atau otomatis meningkatkan penerimaan situs terhadap IP keluar.

Inspeksi HTTPS adalah konfigurasi berbeda yang digunakan pada beberapa jaringan terkelola dan alat penelusuran kesalahan. Aplikasi memercayai otoritas sertifikat yang dikendalikan proksi pemeriksa, yang kemudian dapat membaca trafik sambil mempertahankan koneksi TLS terpisah di masing-masing sisi. Penerusan CONNECT normal tidak memerlukan pemasangan sertifikat seperti itu. Kepercayaan pada sertifikat server proksi HTTPS sendiri terpisah dari izin menyamar sebagai situs.

Cara membaca pengaturan koneksi

Pengaturan proksi memerlukan alamat, port, protokol koneksi, dan autentikasi yang diwajibkan. Protokol dalam URL proksi berlaku pada proksi. Protokol dalam URL tujuan berlaku pada situs.

Perintah curl ini meminta situs HTTPS yang sama melalui dua koneksi proksi berbeda. Ganti nama host dan port proksi dengan nilai yang diberikan untuk metode koneksi terpilih:

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

Perintah pertama terhubung ke proksi melalui HTTP, lalu membuat CONNECT dan TLS ke situs. Perintah kedua terlebih dahulu membuat TLS ke proksi HTTPS, lalu membawa koneksi TLS situs yang terpisah melaluinya. Pada kedua kasus, berikan pula autentikasi yang diwajibkan layanan proksi.

Sekadar mengganti http:// menjadi https:// tidak akan mengubah port yang hanya mendukung HTTP menjadi titik akhir TLS. Jika layanan menyediakan nama host untuk akses HTTPS, gunakan nama host itu: menggantinya dengan IP dapat menyebabkan nama sertifikat tidak cocok.

Label dalam aplikasi memerlukan pembacaan teliti yang sama. Kolom bernama “HTTPS proxy” dapat memilih proksi untuk situs HTTPS sambil tetap terhubung ke proksi melalui HTTP biasa. Dalam curl, variabel HTTPS_PROXY juga memilih proksi untuk tujuan HTTPS; nilainya dapat secara sah dimulai dengan http://. Label menjelaskan permintaan yang menggunakan pengaturan, sementara skema proksi menjelaskan cara koneksi dibuat.

DNS dan trafik yang melewati proksi

Ketika klien HTTP memberikan nama host tujuan, proksi biasanya mencari IP-nya dan terhubung ke sana. Klien melakukan pencarian terpisah jika memerlukan nama host proksi itu sendiri untuk mencapai proksi. Browser juga dapat mengirim kueri DNS untuk prediksi atau fitur lain. Ini merupakan pencarian terpisah; mengatur proksi web tidak merutekan setiap permintaan DNS melaluinya.

Pengaturan berlaku pada trafik yang benar-benar dikirim aplikasi ke proksi. Program lain dapat tetap terhubung langsung, dan daftar pengecualian dapat melewati proksi untuk situs terpilih. Misalnya, merutekan skrip API melalui proksi tidak mengubah rute browser yang tidak terkait. Periksa alamat keluar dari aplikasi dan konfigurasi yang akan menjalankan tugas.

HTTP/2 ke situs dan HTTP/2 ke proksi

HTTP/2 memungkinkan beberapa pertukaran berbagi koneksi menggunakan aliran terpisah. Dengan proksi, penting mengetahui koneksi mana yang mendukungnya. Aplikasi dapat menegosiasikan HTTP/2 dengan situs di dalam terowongan yang dibuat menggunakan CONNECT HTTP/1.1. Proksi meneruskan bita terenkripsi dan tidak perlu memahami pesan HTTP/2 situs.

HTTP/2 antara aplikasi dan proksi adalah kemampuan terpisah. Setiap terowongan CONNECT menggunakan aliran HTTP/2-nya sendiri, sehingga beberapa terowongan dapat berbagi satu koneksi ke proksi. Misalnya, terowongan ke dua situs berbeda dapat menggunakan koneksi itu sambil mempertahankan koneksi tujuan dan sesi TLS situs yang terpisah. Ini mengurangi kebutuhan koneksi klien-ke-proksi tambahan; ini tidak memungkinkan proksi membaca permintaan situs terenkripsi.

Kedua sisi harus mendukung mode terpilih. HTTPS saja tidak menetapkan HTTP/2: proksi HTTPS dapat menggunakan HTTP/1.1. Kinerja juga bergantung pada klien, rute jaringan, beban server, dan penggunaan ulang koneksi. Label HTTP/2 bukan jaminan peningkatan kecepatan untuk setiap tugas.

Terowongan CONNECT biasa juga dapat membawa protokol berbasis TCP lain jika aplikasi dan proksi mengizinkannya, meskipun port tujuan dapat dibatasi. Terowongan itu tidak meneruskan UDP. HTTP/3 menggunakan QUIC melalui UDP, sehingga tidak dapat berjalan melalui terowongan TCP itu dengan cara yang sama. Penerusan UDP berbasis HTTP menggunakan mekanisme tambahan seperti CONNECT-UDP dan memerlukan implementasi yang sesuai. Dukungan HTTPS atau HTTP/2 saja tidak membuktikan adanya dukungan itu.

Kegunaan akses proksi HTTP dan HTTPS

Untuk penjelajahan dan pengujian situs, proksi HTTP dengan CONNECT menyediakan satu metode koneksi untuk tujuan HTTP maupun HTTPS. Tim dapat menggunakannya untuk melihat situs dari jaringan proksi sambil tetap menyerahkan perenderan halaman, cookie, dan login situs kepada browser.

Untuk perayap, klien API, dan pemantau terjadwal, klien HTTP dapat mengirim permintaan melalui IP keluar terpilih sambil mempertahankan URL tujuan. Aplikasi tetap menyiapkan permintaan dan memproses respons. Di dalam terowongan HTTPS, proksi membawa pertukaran itu tanpa perlu mengurai setiap halaman atau panggilan API.

Proksi HTTPS yang dilindungi TLS berguna ketika koneksi ke proksi juga memerlukan perlindungan, termasuk login proksi dan permintaan tujuan. Ini penting ketika koneksi melewati jaringan yang tidak Anda kendalikan. Klien harus mendukung TLS ke proksi itu sendiri; kemampuan membuka situs HTTPS saja tidak cukup.

Membaca kesalahan koneksi

Kegagalan dapat terjadi saat mencapai proksi, membuka terowongan, atau berkomunikasi dengan situs. Tahapnya memberi tahu lebih banyak daripada kode kesalahan saja.

Terowongan dan jabat tangan TLS yang selesai menunjukkan bahwa jalur koneksi berfungsi. Keduanya tidak menjamin situs akan menerima akun, IP keluar, atau permintaan tertentu. Karena itu, tantangan login, CAPTCHA, atau batas permintaan dapat memerlukan penanganan pada tingkat situs atau aplikasi meskipun proksi berfungsi.