Apa Itu Server Proksi SSL dan Bagaimana Cara Kerjanya?

Anda mungkin tidak sedang meneliti server proxy SSL hanya karena rasa ingin tahu semata.

Anda mencoba menyelesaikan sesuatu yang konkret. Tim sosial perlu memeriksa bagaimana kampanye muncul dari lokasi lain. Seorang pengembang perlu menguji alur login yang berperilaku berbeda di belakang HTTPS. Seorang pembeli media ingin memverifikasi bahwa halaman arahan, pengalihan, atau langkah pelacakan berfungsi seperti yang seharusnya ketika lalu lintas diarahkan melalui proxy.

Di sinilah kebingungan dimulai. Sebagian besar penjelasan ditulis untuk tim keamanan dan membanjiri topik ini dengan istilah protokol. Pertanyaan praktisnya lebih sederhana: apa sebenarnya yang dilakukan server proxy SSL, dan mengapa seorang pemasar atau pengembang harus peduli?

Apa Itu Server Proxy SSL

Server proxy SSL adalah lapisan tengah antara pengguna dan situs web atau aplikasi yang menggunakan HTTPS. Ini tidak menggantikan enkripsi. Ini berada di dalam koneksi terenkripsi sehingga lalu lintas dapat diarahkan, diteruskan, atau, dalam beberapa pengaturan, diperiksa sebelum melanjutkan ke tujuannya.

Salah satu cara sederhana untuk membayangkannya adalah sebagai penerjemah tepercaya dalam pertemuan yang aman. Klien berbicara kepada penerjemah, penerjemah berbicara kepada pihak lain, dan kedua percakapan tersebut aman. Pengaturan itu memungkinkan penerjemah melakukan pekerjaan yang berguna di tengah, seperti menegakkan aturan, memeriksa permintaan, atau menyajikan lalu lintas dari jalur jaringan yang berbeda.

Aturan praktis: Jika alur kerja Anda bergantung pada situs web modern, Anda sudah berurusan dengan lalu lintas terenkripsi. Proxy yang tidak dapat bekerja dengan HTTPS tidak akan jauh.

Ini penting karena lalu lintas web terenkripsi bukan lagi kasus niche. Dalam pengukuran skala besar terhadap lalu lintas internet nyata, peneliti menganalisis sekitar 1,4 miliar sesi SSL selama sekitar 1.000 jam dari sekitar 115.000 pengguna dan menemukan bahwa 94,0% koneksi menggunakan TLSv1 sementara 5,9% masih menggunakan SSLv3. Pelajaran besar yang didapat bukanlah nostalgia untuk protokol lama. Ini adalah bahwa transportasi terenkripsi menjadi dasar, yang membuat proxy yang menyadari SSL menjadi diperlukan.

Apa yang sering disalahartikan orang

Pembaca sering menganggap “proxy SSL” berarti “hal yang membuat lalu lintas aman.” Itu tidak sepenuhnya benar. SSL atau TLS adalah lapisan enkripsi itu sendiri. Proxy adalah perantara yang bekerja dengan lalu lintas terenkripsi itu.

Salah satu kesalahpahaman umum lainnya adalah bahwa setiap proxy SSL membaca lalu lintas Anda. Beberapa hanya meneruskan sesi terenkripsi. Lainnya dikonfigurasi untuk mengakhiri satu sesi aman dan membuat sesi aman lainnya, yang memungkinkan visibilitas ke dalam konten. Apakah pemeriksaan terjadi tergantung pada pengaturan dan tujuannya.

• Untuk pemasar: Ini dapat membantu dengan pengujian geo, verifikasi iklan, alur kerja akun, dan melihat apa yang mungkin dilihat pengguna di wilayah atau konteks jaringan lain.
• Untuk pengembang: Ini dapat membantu mereproduksi bug spesifik HTTPS, menguji pengalihan, dan memahami bagaimana aplikasi berperilaku ketika permintaan melewati perantara.
• Untuk tim keamanan: Ini dapat menegakkan kebijakan pada lalu lintas terenkripsi yang sebaliknya akan tidak transparan.

Jadi “lalu apa” itu jelas. Server proxy SSL memberikan tim cara untuk bekerja dengan lalu lintas web terenkripsi alih-alih terhalang olehnya.

Proxy Maju vs Proxy Mundur Dijelaskan

Cara termudah untuk memahami pembagian ini adalah dengan memikirkan tentang ruang surat perusahaan.

Satu meja menangani surat keluar dari karyawan ke dunia luar. Meja lainnya menangani surat masuk dari publik dan mengarahkannya ke tim internal. Proxy maju dan proxy mundur bekerja dengan cara yang sama, kecuali “surat” adalah lalu lintas web.

Apa yang dilakukan proxy maju

Proxy maju berada di depan klien. Klien mengirimkan permintaan ke proxy, dan proxy pergi ke internet atas nama klien. Jika Anda mengelola akun, menguji pengalaman yang sensitif terhadap wilayah, atau mengarahkan otomatisasi browser melalui IP yang berbeda, Anda biasanya memikirkan tentang proxy maju.

Dengan HTTPS, proxy SSL maju dapat melakukan lebih dari sekadar meneruskan. Palo Alto Networks menggambarkan proxy SSL maju sebagai yang mengakhiri sesi TLS klien dan membuat sesi TLS kedua ke server tujuan. Itulah mekanisme yang memungkinkan dekripsi dan pemeriksaan ketika pemeriksaan diaktifkan.

• Tujuan sisi klien yang khas: Menyembunyikan atau mengganti identitas jaringan klien, menerapkan kebijakan, atau memeriksa lalu lintas keluar.
• Contoh pemasaran: Seorang manajer kampanye memeriksa apakah halaman tujuan teratasi dengan benar ketika lalu lintas keluar melalui jaringan seluler di wilayah lain.
• Contoh pengembang: Alur kerja QA menjalankan lalu lintas aplikasi melalui proxy untuk mengamati pengalihan dan perilaku API dalam kondisi HTTPS yang nyata.

Apa yang dilakukan proxy mundur

Proxy mundur berada di depan server. Pengguna publik terhubung ke proxy terlebih dahulu, dan proxy memutuskan layanan backend mana yang harus menangani permintaan. Ini umum ketika sebuah situs ingin satu pintu depan yang bersih untuk banyak layanan internal.

Untuk tim aplikasi, proxy mundur sering kali menjadi tempat di mana pengakhiran SSL, pengalihan permintaan, penerusan header, dan kontrol lalu lintas terjadi. Mereka lebih sedikit tentang menyembunyikan klien dan lebih banyak tentang melindungi dan mengorganisir sisi server.

Proxy maju mewakili klien. Proxy mundur mewakili server.

Yang mana yang cocok untuk pekerjaan Anda

Jika tim Anda berbicara tentang pembuatan akun, pemeriksaan iklan, otomatisasi browser, solusi pencegahan pengikisan, atau QA yang ditargetkan secara geo, Anda kemungkinan besar berurusan dengan kasus penggunaan proxy maju. Jika tim Anda berbicara tentang penyeimbangan beban, penanganan HTTPS masuk, pengiriman aplikasi, atau memusatkan sertifikat, itu menunjukkan wilayah proxy mundur.

Orang juga sering bingung karena keduanya dapat mengakhiri TLS. Perbedaannya bukan pada langkah enkripsi. Perbedaannya adalah di sisi mana proxy berdiri di depan.

Bagaimana Pengakhiran TLS dan Pemeriksaan Bekerja

Frasa yang menakutkan bagi sebagian besar orang non-jaringan adalah pengakhiran TLS. Ini terdengar invasif, tetapi idenya sederhana setelah Anda menerjemahkannya ke dalam istilah alur kerja.

Pikirkan proxy sebagai penerjemah tepercaya di pos pemeriksaan yang aman. Klien menyerahkan pesan terenkripsi kepada proxy. Proxy membukanya, memeriksa apa yang perlu diperiksa, lalu menguncinya lagi sebelum meneruskannya. Tujuan melihat sesi aman yang valid, dan klien juga melihat sesi aman, tetapi sebenarnya ada dua percakapan aman terpisah dengan proxy di tengah.

Proses dalam bahasa sederhana

1. Klien terhubung dengan aman. Sebuah browser, aplikasi, atau skrip otomatisasi memulai sesi HTTPS.
2. Proxy menerima sesi aman itu. Alih-alih meneruskannya secara membabi buta, proxy menjadi titik akhir untuk percakapan terenkripsi pertama itu.
3. Proxy mendekripsi lalu lintas. Pada saat ini, ia dapat memeriksa detail permintaan jika konfigurasi mengizinkannya.
4. Proxy membuka sesi aman baru ke tujuan. Server situs atau aplikasi menerima koneksi terenkripsi kedua dari proxy.
5. Respons kembali melalui jalur yang sama. Proxy dapat memeriksa, memodifikasi, atau sekadar meneruskannya sebelum mengembalikannya kepada klien melalui enkripsi.

Di tingkat desain jaringan, inilah mengapa server proxy SSL sering digambarkan sebagai perantara Lapisan 7 yang transparan. Juniper dan dokumentasi produk terkait menggambarkan proxy SSL sebagai enkripsi dan dekripsi SSL/TLS antara klien dan server, yang memungkinkan pemeriksaan payload aplikasi, header HTTP, URL, dan konten yang tidak dapat dianalisis oleh proxy lapisan bawah, sambil juga menambah kompleksitas operasional seputar kepercayaan dan re-enkripsi, seperti yang dicatat dalam penjelasan Juniper tentang perilaku proxy SSL.

Mengapa tim menggunakan pemeriksaan sama sekali

Jika lalu lintas tetap terenkripsi dari ujung ke ujung tanpa visibilitas perantara, proxy dapat mengarahkannya tetapi tidak memahaminya. Itu membatasi apa yang dapat Anda lakukan. Setelah proxy dapat mengakhiri dan membangun kembali TLS, ia dapat mendukung alur kerja yang sadar konten.

• Tinjauan keamanan: Tim dapat memeriksa lalu lintas terenkripsi untuk malware, pelanggaran kebijakan, atau tujuan yang diblokir.
• Analisis permintaan: Pengembang dapat melihat header, jalur, dan perilaku terkait payload yang penting saat melakukan debug aplikasi.
• Titik kontrol: Tim operasional dapat menerapkan aturan berdasarkan konten, bukan hanya tujuan dan port.

Ketika sebuah aplikasi “berfungsi baik tanpa proxy” tetapi rusak saat menggunakan proxy, masalahnya biasanya bukan sihir. Ini sering kali terkait dengan kepercayaan, header, pengalihan, atau penanganan sertifikat.

Itulah bagian yang sering dilewatkan banyak panduan. Pengakhiran TLS sangat kuat, tetapi itu mengubah bentuk koneksi. Setelah proxy menjadi bagian dari percakapan, aplikasi, browser, atau tumpukan otomatisasi Anda mungkin perlu mempercayai rantai sertifikat, mempertahankan header dengan benar, dan menangani pengalihan dengan lebih hati-hati.

Proxy SSL vs Proxy HTTP dan SOCKS

Orang sering menggunakan kata “proxy” seolah semua jenis proxy melakukan hal yang sama. Mereka tidak. Bagi pemasar dan pengembang, perbedaan terbesar adalah apakah proxy memahami lalu lintas web terenkripsi cukup dalam untuk memeriksa atau memanipulasinya.

Perbandingan jenis proxy

Apa artinya dalam praktik

Proxy HTTP berfokus pada web, tetapi tidak secara otomatis memberi Anda visibilitas yang berarti ke dalam lalu lintas terenkripsi. Proxy SOCKS lebih seperti pipa transportasi. Ini bisa fleksibel, tetapi biasanya tidak tahu atau peduli apa yang ada di dalam paket.

Proxy SSL menonjol ketika pekerjaan bergantung pada pemahaman atau pengendalian apa yang terjadi di dalam sesi HTTPS. Jika Anda perlu melakukan debug pengalihan, memeriksa header, menerapkan kebijakan lalu lintas, atau menguji bagaimana alur kerja terenkripsi berperilaku melalui perantara, di situlah proxy SSL mendapatkan nilainya.

• Pilih proxy SSL ketika sesi terenkripsi itu sendiri adalah hal yang perlu Anda kerjakan.
• Pilih proxy HTTP ketika tugasnya lebih sederhana dan terkait dengan permintaan web gaya browser.
• Pilih SOCKS ketika Anda terutama membutuhkan jalur generik untuk lalu lintas dan tidak memerlukan kesadaran konten.

Kasus Penggunaan Umum untuk Server Proxy SSL

Cara paling berguna untuk memikirkan server proxy SSL bukan sebagai perangkat keamanan terlebih dahulu, tetapi sebagai titik kontrol. Ini memberi tim satu tempat di mana lalu lintas terenkripsi dapat diarahkan, diperiksa, dan dibentuk untuk mendukung pekerjaan yang nyata.

Bagi seorang pemasar, itu mungkin berarti melihat halaman yang sama yang akan dilihat pengguna di konteks jaringan lain. Bagi seorang pengembang, itu mungkin berarti mereproduksi bug yang hanya muncul di belakang HTTPS dan proxy. Bagi tim operasional, itu mungkin berarti menambahkan pemeriksaan di mana lalu lintas terenkripsi akan menjadi tidak transparan.

Skenario pemasaran dan pembelian media

Seorang manajer media sosial sering perlu beroperasi di lingkungan di mana perilaku platform sensitif terhadap lokasi, identitas jaringan, dan konteks browser. Mengarahkan lalu lintas melalui proxy yang mendukung SSL dapat membuat sesi tersebut dapat digunakan sambil mempertahankan perilaku HTTPS yang diharapkan oleh platform.

Seorang spesialis afiliasi atau PPC menghadapi masalah yang berbeda. Iklan, prelanders, pengalihan, dan tawaran akhir tidak selalu muncul dengan cara yang sama di mana saja. Pengaturan proxy membantu memverifikasi apakah perjalanan pengguna konsisten ketika lalu lintas keluar melalui wilayah atau profil jaringan seluler yang berbeda.

• Verifikasi iklan: Konfirmasi bahwa kampanye menampilkan halaman, bahasa, dan alur pengalihan yang diharapkan dari pasar target.
• Operasi akun: Mendukung login, penanganan sesi, dan manajemen sehari-hari di mana platform sensitif terhadap perubahan sinyal jaringan.
• Pemeriksaan kompetitif: Tinjau halaman publik dan tawaran seperti yang muncul di bawah jalur akses yang berbeda, tanpa bergantung pada koneksi kantor Anda.

Skenario pengembang dan QA

Tim QA menggunakan proxy karena banyak bug tidak muncul di lingkungan lokal yang bersih. Mereka muncul ketika permintaan dialihkan, rantai sertifikat berubah, atau aplikasi menerima header yang diteruskan berbeda dari yang diharapkan.

Salah satu masalah praktis yang terdokumentasi dengan pengaturan reverse-proxy adalah bahwa aplikasi dapat kehilangan jejak skema permintaan asli kecuali mereka mempercayai header yang diteruskan seperti HTTP_X_FORWARDED_PROTO. Ketika kepercayaan itu tidak dikonfigurasi, login dan pengalihan dapat berulang atau rusak, seperti yang dibahas dalam penjelasan ini tentang efek proxy SSL pada perilaku aplikasi.

Catatan lapangan: “Mengapa aplikasi saya rusak?” sering kali adalah masalah kesadaran proxy, bukan masalah kualitas aplikasi.

• QA tergantung geo: Uji formulir, alur lokal, dan variasi konten di bawah kondisi routing yang berbeda.
• Debug pengalihan: Lacak di mana permintaan HTTPS mengubah skema, host, atau perilaku sesi.
• Dukungan otomatisasi: Jalankan tugas browsing yang diprogram melalui perantara yang stabil yang mempertahankan transportasi aman.

Penggunaan infrastruktur dan kebijakan

Tim keamanan dan operasional peduli tentang proxy SSL karena alasan yang lebih tradisional. Mereka dapat memeriksa aliran terenkripsi, menerapkan aturan penyaringan, dan memusatkan penegakan kebijakan di mana sebaliknya hanya ciphertext yang akan terlihat.

Jika pekerjaan Anda lebih dekat dengan pertumbuhan atau QA, terjemahan yang berguna adalah ini: mekanisme yang sama yang membantu tim keamanan memeriksa lalu lintas adalah apa yang juga membantu Anda menguji, memverifikasi, dan memecahkan masalah perjalanan pengguna terenkripsi.

Trade-Off Keamanan dan Kinerja

Proxy SSL tidak secara otomatis merupakan peningkatan keamanan. Ini dapat meningkatkan visibilitas dan kontrol, tetapi juga menciptakan tempat baru di mana lalu lintas sensitif didekripsi. Itu menjadikan proxy itu sendiri bagian dari permukaan serangan Anda.

Analisis independen telah menunjukkan bahwa proxy biasanya hanya dapat meneruskan data terenkripsi, sementara proxy SSL gaya man-in-the-middle dapat membacanya dan memodifikasinya setelah menyamar sebagai tujuan. Itulah mengapa kepercayaan sertifikat, konfigurasi titik akhir, dan kebersihan operasional sangat penting, seperti yang dijelaskan dalam analisis ini tentang proxy yang memutuskan koneksi SSL.

Biaya keamanan dari visibilitas

Kelebihan dari pemeriksaan sangat jelas. Anda dapat mendeteksi hal-hal di dalam lalu lintas terenkripsi yang sebaliknya akan tetap tersembunyi. Kekurangan juga sama jelasnya setelah Anda mengatakannya dengan gamblang: proxy melihat data yang didekripsi.

• Risiko terpusat: Jika proxy dikonfigurasi dengan salah atau dikompromikan, itu dapat mengekspos sejumlah besar lalu lintas sensitif.
• Beban kepercayaan: Perangkat dan aplikasi klien perlu mempercayai perilaku sertifikat proxy, atau mereka akan gagal dengan cara yang bising dan membingungkan.
• Pertanyaan privasi: Tim perlu batasan yang jelas mengenai apa yang harus diperiksa dan apa yang harus dibiarkan sendiri.

Biaya kinerja untuk melakukan lebih banyak pekerjaan

Pemeriksaan juga menambah overhead. Proxy harus mengakhiri satu sesi TLS, memeriksa atau memproses lalu lintas, dan kemudian membangun atau mempertahankan sesi aman lainnya. Itu berarti lebih banyak pekerjaan kriptografi dan lebih banyak bagian yang bergerak di jalur permintaan.

Bagi seorang pemasar yang memeriksa halaman arahan sesekali, overhead itu mungkin tidak mencolok. Untuk alur kerja otomatisasi atau lingkungan volume tinggi, jabat tangan tambahan dan re-enkripsi dapat menjadi faktor operasional yang nyata. Jika proxy tidak cukup kuat atau ditempatkan dengan buruk, itu dapat menjadi hambatan alih-alih pembantu.

Pola pikir yang berguna adalah memperlakukan proxy SSL sebagai satu titik kepercayaan. Jika Anda tidak akan memusatkan lalu lintas sensitif di sana dengan percaya diri, jangan dekode di sana.

Penerapan yang paling kuat bersifat selektif. Mereka tidak memeriksa semuanya hanya karena mereka bisa. Mereka mendefinisikan lalu lintas mana yang perlu terlihat, siapa yang mengontrol sertifikat, dan bagaimana kegagalan akan dipantau dan dikendalikan.

Konfigurasi dan Pemilihan Proxy Seluler

Hasil yang baik dengan server proxy SSL biasanya kembali pada satu kebenaran yang membosankan: kualitas pengaturan lebih penting daripada label pada produk. Jika rantai kepercayaan, header, atau penanganan sesi salah, proxy akan terlihat rusak bahkan ketika itu melakukan persis apa yang Anda perintahkan.

Itu menjadi lebih penting sekarang karena infrastruktur proxy terus tumbuh seiring lalu lintas terenkripsi menjadi standar. Satu perkiraan pasar menempatkan pasar server proxy global di USD 4,29 miliar pada tahun 2023 dengan proyeksi USD 7,59 miliar pada tahun 2032, sementara ringkasan industri mencatat bahwa 70,1% dari situs web teratas telah bermigrasi ke TLS 1.3 pada Mei 2024. Pelajaran praktisnya sederhana: penanganan yang sadar SSL semakin menjadi infrastruktur normal, bukan kasus tepi spesialis.

Apa yang perlu diperiksa sebelum Anda menerapkan

• Kepercayaan sertifikat: Pastikan sisi klien dan sisi aplikasi mempercayai apa yang perlu mereka percayai. Jika tidak, kegagalan HTTPS dapat terlihat acak.
• Header yang diteruskan: Konfirmasi bahwa aplikasi menerima dan mempercayai header yang mempertahankan skema asli dan konteks permintaan.
• Pemeriksaan selektif: Hanya dekode lalu lintas yang benar-benar perlu diperiksa atau dipecahkan masalahnya.
• Pencatatan dan pemantauan: Perhatikan loop pengalihan, kegagalan jabat tangan, dan kerusakan spesifik aplikasi alih-alih mengasumsikan proxy bersifat transparan.

Bagaimana pemilihan proxy seluler mengubah gambaran

Jika kasus penggunaan Anda melibatkan platform sosial, pemeriksaan iklan, alur pendaftaran aplikasi, atau QA yang berfokus pada seluler, jenis jaringan menjadi penting. Proxy seluler dapat lebih baik mencocokkan kondisi yang diharapkan oleh platform tersebut, terutama ketika Anda perlu lalu lintas terlihat seolah-olah berasal dari koneksi seluler yang nyata daripada saluran kantor tetap.

Ketika membandingkan opsi, fokuslah pada kesesuaian praktis: kepercayaan IP, kontrol rotasi, batasan lalu lintas, dan apakah penyedia mendukung alur kerja yang sebenarnya Anda jalankan. Misalnya, Evoproxy menawarkan port proxy seluler Prancis dengan opsi pribadi dan bersama, rotasi yang dapat disesuaikan, dan akses IP seluler yang ditujukan untuk kasus penggunaan seperti manajemen media sosial, pengujian iklan, pekerjaan akun, dan QA yang bergantung pada geo.

Jika tim Anda membutuhkan akses proxy seluler Prancis untuk pengujian aman, alur kerja akun, atau verifikasi kampanye, Evoproxy adalah salah satu opsi untuk dievaluasi. Sesuaikan jenis proxy dengan pekerjaan, jaga kepercayaan sertifikat dan header tetap bersih, dan perlakukan pemeriksaan SSL sebagai alat yang disengaja, bukan pengaturan default.