Mengkonfigurasi squid proxy server di jaman sekarang tidak semudah seperti sebelumnya saat protokol service request masih menggunakan "http" bukan "https". Di saat sekarang saat kalian menginstall dan mengkonfigurasi squid proxy server seperti sebelumnya bisa di pastikan tidak akan ada dampaknya.
Di masa sekarang saat kita ingin mencache atau simpan suatu konten internet di media lokal server kita maka di butuhkan squid yang bisa menghandle HTTP Over TLS/ SSL (HTTPS).
Dibawah ini sedikit penjelasan clue dan terjemahan soal feature HTTPS di SQUID, ada baiknya di pahami sebelum mempraktekannya langsung dari semua sumber tentang konfgurasi squid bisa memcache https, karena memang konfigurasi ini terbilang masih rumit dan masiih banyak bug.
Sumber asli konten :
https://wiki.squid-cache.org/Features/HTTPS#CONNECT_tunnel_through_Squid
SILAHKAN SIMAK
Saat browser menemukan https://URL, ada satu dari dua hal berikut yang terjadi:
- membuka koneksi SSL/ TLS langsung ke server asli atau
- membuka terowongan TCP melalui squid ke server asli menggunakan metode permintaan CONNECT .
Interaksi
squid dengan kedua jenis lalu lintas ini akan dibahas di bawah.
Terowongan
CONNECT
Metode CONNECT adalah cara untuk melakukan koneksi tunnel apapun melalui HTTP proxy. Secara default, proxy tersebut menetapkan koneksi TCP ke server yang ditentukan, merespons dengan respons HTTP 200 (Connection Established), dan kemudian menyekop atau mencicil paket bolak-balik antara klien dan server tanpa memahami atau menafsirkan lalu lintas terowongannya.
CONNECT tunnel melalui Squid
Saat
browser menetapkan tunnel CONNECT melalui squid, Access Controls dapat
mengendalikan permintaan CONNECT, namun hanya tersedia informasi secara terbatas.
Misalnya, banyak bagian umum dari permintaan URL tidak ada dalam permintaan
CONNECT seperti :
•
Skema atau protokol URL (misalnya, http: //, https: //,
ftp: // , voip://, itunes://, atau telnet:// ),
•
Jalur/ patch URL (misalnya, /index.html atau/
secure /image / ),
•
dan string kueri (misalnya ? a=b &c=d )
Dengan HTTPS, semua bagian yang di atas hadir dalam permintaan HTTP yang
dienkapsulasi dan mengalir melalui terowongan, namun squid tidak
memiliki akses ke pesan yang terenkripsi tersebut. Protokol tunnelled lainnya
mungkin tidak menggunakan pesan HTTP dan URL (misalnya, telnet).
Penting untuk diperhatikan
bahwa protokol yang melewati CONNECT tidak terbatas pada apa yang biasanya
ditangani squid. Logikanya, apa pun yang menggunakan koneksi TCP dua arah
dapat dilewatkan melalui terowongan CONNECT. Inilah sebabnya mengapa default
ACL squid dimulai dengan deny
CONNECT! SSL_Ports dan mengapa kita harus memiliki alasan bagus untuk
menempatkan jenis aturan allow pada aturan di atas.
Intercepting CONNECT tunnels (Mencegat
terowongan CONNECT)
Browser
mengirimkan permintaan CONNECT saat dikonfigurasi untuk berkomunikasi/ memakai proxy.
Jadi, tidak perlu mencegat permintaan CONNECT. TBD: Dokumentasi tentang
apa yang terjadi pada squid tidak mencegat permintaan CONNECT, entah karena
squid telah salah dikonfigurasi untuk mencegat lalu lintas yang ditujukan ke
proxy lain atau karena klien yang mungkin jahat mengirim permintaan CONNECT
buatan tangan untuk mengetahui bahwa itu akan dicegat.
Terowongan CONNECT Bumping
PERINGATAN: HTTPS dirancang untuk memberikan pengguna
harapan akan privasi dan keamanan. Mengekstrusi terowongan HTTPS tanpa
persetujuan atau pengetahuan pengguna mungkin melanggar norma etika dan mungkin
melanggar hukum di yurisdiksi anda. Fitur dekripsi squid yang dijelaskan di
sini atau di tempat lain dirancang untuk diterapkan dengan persetujuan pengguna
atau paling tidak di lingkungan di mana dekripsi tanpa persetujuan bisa di
sebut legal. Fitur-fitur ini juga menggambarkan mengapa pengguna harus
berhati-hati dalam mempercayai koneksi HTTPS dan mengapa link terlemah dalam
rantai perlindungan HTTPS sedikit rapuh. Mengekstrusi terowongan HTTPS
merupakan kategori serangan man-in-the-middle jika di lihat dari sudut pandang
keamanan jaringan secara keseluruhan.
Squid
SslBump dan fitur yang
terkait dengannya dapat digunakan untuk mendekripsi terowongan HTTPS CONNECT
saat mereka melewati proxy squid. Hal ini memungkinkan untuk menangani pesan di
terowongan HTTP seolah-olah pesan HTTP biasa, termasuk menerapkan kontrol akses
terperinci dan melakukan adaptasi konten (misalnya, memeriksa request body terhadap kebocoran informasi dan memeriksa
respon terhadap virus). Kesalahan konfigurasi, bug squid, dan serangan
berbahaya dapat menyebabkan pesan yang tidak terenkripsi keluar dari batas squid.
Dari sudut pandang browser, pesan yang dienkapsulasi tidak dikirim ke proxy.
Dengan demikian, keterbatasan intersepsi umum, seperti ketidakmampuan untuk
mengotentikasi permintaan tertanam individual, berlaku di sini juga.
Sambungan
SSL / TLS langsung
Saat
browser membuat sambungan aman langsung dengan server asli, tidak ada
permintaan HTTP CONNECT. Permintaan HTTP pertama kali yang dikirim pada koneksi
semacam itu sudah dienkripsi. Dalam kebanyakan kasus, squid keluar dari
lingkarannya: Squid tidak tahu apa-apa tentang koneksi itu dan tidak dapat
memblokir atau proxy lalu lintas itu. Pengecualian terhadap reverse proxy dan intersepsi
dijelaskan di bawah ini.
Sambungan SSL/ TLS langsung ke
reverse proxy
Squid-2.5
atau yang lebih baru dapat menghentikan koneksi TLS atau SSL. Anda harus
membangun/ build squid dengan --enable-ssl pada saat install/ re-build/
compile. Lihat https_port untuk informasi lebih lanjut. Squid-3.5 dan yang
berikutnya dapat melakukan autodetek
terhadap ketersediaan perpustakaan GnuTLS dan mengaktifkan fungsinya jika
tersedia. OpenSSL atau LibreSSL harus diaktifkan secara eksplisit dengan opsi
configure --with-openssl saat
mencompile/merebuild . Jika library/ perpustakaan dipasang di lokasi
non-standar, anda mungkin perlu menggunakan opsi konfigurasi --with-foo=PATH.
Lihat configure --help pada terminal untuk rinciannya.
Ini mungkin paling berguna dalam konfigurasi pengganti
(aka, http accelerator, reverse proxy). Cukup konfigurasikan Squid dengan
konfigurasi proxy normal dengan menggunakan port 443 dan rincian sertifikat SSL
pada baris https_port .
Mencegat koneksi SSL / TLS
langsung
Hal
ini dimungkinkan untuk mencegat koneksi HTTPS ke server asli di https_port
squid. Ini mungkin berguna di lingkungan pengganti (aka, http accelerator,
reverse proxy), namun terbatas pada situasi di mana squid dapat mewakili server
asli menggunakan sertifikat SSL server assli tersebut. Dalam kebanyakan
situasi, penyadapan koneksi HTTPS langsung tidak akan bekerja dan tidak ada
gunanya karena squid tidak dapat melakukan apapun dengan lalu lintas
terenkripsi - Squid bukanlah proxy tingkat TCP.
Bumping koneksi SSL/ TLS langsung
PERINGATAN: HTTPS dirancang untuk memberi pengguna harapan akan
privasi dan keamanan. Mengekstrusi terowongan HTTPS tanpa persetujuan atau
pengetahuan pengguna mungkin melanggar norma etika dan mungkin melanggar hukum
di yurisdiksi anda. Fitur dekripsi squid yang dijelaskan di sini atau di tempat
lain dirancang untuk diterapkan dengan persetujuan pengguna atau, paling
tidak, di lingkungan di mana dekripsi tanpa persetujuan itu di sebut legal.
Fitur-fitur ini juga menggambarkan mengapa pengguna harus berhati-hati dalam
mempercayai koneksi HTTPS dan mengapa link terlemah dalam rantai perlindungan
HTTPS sedikit rapuh. Mengekstrusi terowongan HTTPS merupakan serangan man in
the middle dari sudut pandang keamanan jaringan secara keseluruhan.
Kombinasi squid
NAT
Interception , SslBump , dan fitur yang terkait dengannya dapat
digunakan untuk mencegat koneksi HTTPS langsung dan mendekripsi pesan HTTPS
saat mereka melewati proxy squid. Hal ini memungkinkan untuk menangani pesan HTTPS
yang dikirim ke server asli seolah-olah pesan HTTP biasa, termasuk menerapkan
kontrol akses terperinci dan melakukan adaptasi konten (misalnya, memeriksa
request body untuk kebocoran informasi dan memeriksa respon dari virus).
Kesalahan konfigurasi, bug squid, dan serangan berbahaya dapat menyebabkan
pesan yang tidak terenkripsi keluar dari batas squid.
Saat ini,
lalu lintas squid-to-client pada koneksi HTTPS langsung yang dicegat/
intercept tidak dapat menggunakan Dynamic Certificate Generation , ini
akan menyebabkan peringatan pada browser dan membuat konfigurasi seperti itu
hampir tidak praktis. Keterbatasan inilah yang akan ditangani oleh proyek
bagian bump-server-first.
Dari sisi
browser, pesan yang dicegat/ intercept tidak dikirim ke proxy. Dengan demikian,
keterbatasan intersepsi secara umum, seperti ketidakmampuan untuk
mengotentikasi permintaan berlaku untuk transaksi yang disadap/ bumped tercegat
juga.
Koneksi browser-Squid
terenkripsi
Sementara
upaya perancangan HTTPS difokuskan pada komunikasi end-to-end, cara ini akan menyenangkan karena dapat
mengenkripsi koneksi browser ke proxy (tanpa membuat terowongan CONNECT yang
memblokir squid dari pengaksesan dan penyimpanan konten). Ini akan memungkinkan
misalnya penggunaan proxy jarak jauh yang aman yang berada di jaringan lain.
Squid dapat
menerima lalu lintas proxy biasa menggunakan https_port dengan cara yang sama
seperti squid menggunakan perintah http_port . Sayangnya, browser modern yang
populer tidak mengizinkan konfigurasi koneksi proxy terenkripsi TLS/ SSL. Ada
laporan bug yang muncul terhadap sebagian besar browser tersebut sekarang,
menunggu dukungan muncul. Jika anda berminat, tolong bantu tim browser agar hal
itu terjadi.
Di lain hal,
trik menggunakan stunnel atau terowongan SSH diperlukan untuk mengenkripsi
koneksi browser-ke-proxy sebelum meninggalkan mesin klien. Ini agak berat di
jaringan dan bisa malah lambat hasilnya.
Chrome
Browser
Chrome dapat terhubung ke proxy melalui koneksi SSL jika dikonfigurasi untuk
menggunakannya di file PAC atau tombol perintah. Konfigurasi via GUI nampaknya
tidak atau belum dimungkin.
Firefox
Browser
Firefox 33.0 dapat terhubung ke proxy melalui koneksi TLS jika dikonfigurasi
untuk menggunakannya dalam file PAC. Konfigurasi via GUI nampaknya tidak atau
belum dimungkin. meski ada hack hack untuk embedding
logika PAC .
Masih ada
bug penting yang terbuka:
- Menggunakan otentikasi sertifikat klien ke proxy: https://bugzilla.mozilla.org/show_bug.cgi?id=209312
Jika anda
memiliki masalah saat menambahkan trust untuk cert proxy, ada sebuah
proses oleh
Patrick McManus untuk menyelesaikannya.
