deep packet fucking inspection
transparent proxies, DNS leaks, and another PF shit
Masih ingat ketika pengguna IndiHome tidak dapat mengakses Netflix? Atau, sampai hari ini kamu masih belum bisa mengakses Reddit?
Atau, familiar dengan tangkapan layar seperti gambar diatas?
Gue menggunakan Biznet sebagai penyedia layanan Internet yang gue gunakan, karena gue rasa ISP gak terlalu banyak gaya daripada ISP lain. Jika kita membaca konten yang ada di halaman biznetnetworks.com/en/safesurf tersebut, cuplikannya adalah seperti ini:
Situs Terlarang
Mohon maaf,
Situs ini tidak dapat diakses. Situs ini termasuk dalam situs yang tidak boleh diakses melalui jaringan ini karena terindikasi mengandung pornografi, judi, phising/malware, SARA ataupun Proxy.
Sesuai dengan Peraturan Pemerintah Republik Indonesia yang menunjuk pada Undang-Undang Nomor 36 Tahun 1999 tentang Telekomunikasi Pasal 21, "Penyelenggara telekomunikasi dilarang melakukan kegiatan usaha penyelenggaraan telekomunikasi yang bertentangan dengan kepentingan umum, kesusilaan, keamanan atau ketertiban umum."
Dan ini dapat dimengerti.
Biznet adalah “penyelenggara telekomunikasi” dan berarti harus tunduk dengan pasal 21 tersebut terkait pelarangan melakukan kegiatan usaha akan penyelenggaraan telekomunikasi yang bertentangan dengan kepentingan umum, kesusilaan, keamanan atau ketertiban umum apapun itu.
Untuk dapat memenuhi peraturan tersebut, Biznet harus mengetahui situs apa yang diakses oleh pelanggan nya. Banyak cara untuk melakukannya, dan yang paling umum adalah dengan menggunakan Transparent Proxy berikut dengan DNS query yang dilakukan di server tempat proxy tersebut berada.
Dan jika ada seseorang/sekelompok datang ke Biznet untuk meminta bukti bahwa pelanggannya dengan nama X mengakses situs evilfactorylabs.org pada 21 Juni 2021 13:37 WIB, besar kemungkinan Biznet bisa membuktikannya dengan memberikan data, karena sederhana: Biznet bisa mengumpulkannya terlepas untuk kepentingan apapun itu.
Transparent proxy, the good one
Harga bandwidth masih relatif mahal, egress bandwidth (traffic keluar) dari server yang ada di Google Cloud Jakarta ke internet (misal seluruh dunia) saja $0.19/GiB.
Penggunaan internet normal rata-rata gue sekitar 4GB per-hari. Dalam sebulan, jika paket internet yang gue gunakan untuk ber-internet gue teruskan ke server gue yang ada di GCP Jakarta, biaya untuk bandwidth tersebut saja sekitar $22,8/bulan atau setara dengan 328,835 IDR yang kurang lebih seharga paket internet salah satu ISP dengan kecepatan 10MBps. Belum untuk biaya lain seperti vCPU, SSD, dan RAM.
Jika gue menggunakan transparent proxy di server gue tersebut, mungkin gue bisa menghemat MB-GB per-bulan. Untuk mengakses substack.com (yang sudah memblokir trackers) saja memuat 1.93MB (uncompressed, non-cache) atau 701.90 KB (gzipped, no-cache) dan 1.42MB (uncompressed, cached) atau 22.97KB (gzipped, cached).
Let’s say gue membuka substack.com per-hari 6x, berarti ada ~10,45MB egress bandwidth per-hari yang gue keluarkan dengan catatan hanya permintaan pertama yang tidak ter-cache oleh peramban.
Yang berarti, dalam sebulan, ada 313,5MB permintaan hanya untuk halaman substack.com sendiri. Biaya tersebut masih relatif murah, bahkan tidak sampai 5,000 IDR. Namun poinnya, bagaimana bila ada 50 orang yang mengakses substack.com 6x per-hari? Berarti egress badwidth per-bulan tersebut sekitar 15GB hanya untuk mengakses substack.com.
Transparent Proxy bisa membantu disini.
Konten yang bernama substack.bundle.js?v=10e3a6-17a20fcbc00 yang berada di cdn.substack.com/min dan berukuran 1,06MB (uncompressed) akan selalu sama dengan 50 pengguna lain yang mengakses konten tersebut juga. Ada ~9,5GB penghematan perbulan dan plus mendapatkan latensi yang lebih rendah karena server gue tidak perlu berkomunikasi dengan server yang dipakai Substack yang entah berada dimana.
Transparent Proxy hampir sama cara kerjanya dengan Reverse Proxy yang biasa digunakan oleh penyedia layanan CDN ataupun perusahaan yang menjalankan bisnis di internet. Jika transparent proxy adalah proxy berada sebelum mengakses internet, reverse proxy sesederhana proxy yang berada setelah mengakses internet.
Anyway, transparent proxy (gue percaya) tidak selalu digunakan oleh ISP meskipun yang umum menggunakannya adalah ISP. Terlebih sekarang adopsi HTTPS sudah semakin banyak, yang berarti penggunaan inti dari transparent proxy menjadi sedikit tidak berguna karena memiliki proses CONNECT jika tujuannya adalah untuk melakukan cache khususnya karena proxy tidak mengetahui “path” apa yang ingin diakses, thanks to e2e encryption yang mencegah MiTM attack.
Sebagai kesimpulan: Ya, the good one dari transparent proxy hanyalah untuk di permintaan HTTP yang semoga sudah tidak ada yang menggunakan murni protokol tersebut lagi.
Deep Packet Inspection
Apakah HTTPS saja sudah cukup? Tentu tidak.
Let’s say gue adalah ISP dan masih menggunakan transparent proxy. Gue masih bisa mengetahui situs apa yang pelanggan gue kunjungi sekalipun melalui protokol HTTPS.
Karena gue tau (sebagai ISP) kalau www.pornhub.com harusnya gue blokir, dan karena pelanggan gue mengakses situs yang menggunakan HTTPS jadi gue gak bisa memodifikasi response, jadi tinggal gue jawab aja dengan alamat IP yang mengarah ke server gue yang khusus untuk menampilkan halaman “safe surf”.
Dan karena klien/peramban tau bahwa permintaan awal dan respon akhir berbeda, maka peramban tidak akan menampilkan halaman tersebut yang biasanya menampilkan alert HTTPS alert.
Kalo gak ada alert, palingan gak bisa akses port 443 nya 202.169.44.80 (Biznet SafeSurf).
Anyways, banyak alasan mengapa ISP melakukan DPI, termasuk untuk alasan keamanan.
Namun yang pasti untuk melakukan censorship dalam bentuk apapun itu.
Let’s say di Indonesia dilarang menggunakan VPN, khususnya Wireguard. Dengan DPI, ISP dapat menentukan jika paket tersebut adalah koneksi VPN dengan cara melihat target port nya default WG misalnya (51820).
Atau, bisa juga untuk menganalisa jika paket yang masuk/keluar bukanlah serangan DDoS yang misalnya adalah ICMP flood dengan ukuran paket yang kurang rasional.
Apapun.
Bisa di level hardware seperti Fortigate nya Fortinet ataupun software yang mana yang gue tahu dan populer (dan Open Source) untuk hal-hal terkait DPI ini adalah ntop, prinsipnya, jika gue bisa mencegah pengguna untuk mengakses situs phising, berarti gue bisa mencegah pengguna untuk mengakses situs apapun itu.
Namun poinnya bukan disitu, jika ISP mengumpulkan situs-situs apa saja yang lo kunjungi, pertanyaan pertamanya, lo oke enggak dengan itu? Pertanyaan kedua, apakah yang dikumpulkan cuma tok alamat situs aja atau tersambung dengan data pribadi lo juga yang alias gak penting kalau alasannya untuk melindungi "keamanan pelanggan”, dan pertanyaan ketiga, apakah lo bisa memilih untuk enggak berpartisipasi misalnya karena alasan apapun itu.
Yang paling banyak gaya adalah jaringan Telkom, kalau gue lagi di Starbucks, meskipun sudah melewati Captive Portal (yang akan gue bahas nanti) router gue tidak bisa membuat sambungan dengan port 51820 (Wireguard) di server gue yang alasannya mungkin hanya Telkom yang tau, dan ketika itu terjadi gue mau tidak mau setup perangkat gue untuk menggunakan SOCKS5 proxy (dan tinggal menunggu mereka memblokir akses keluar ke port 22).
Atau mungkin mereka memblokir semua paket UDP yang keluar kecuali untuk port 53 alias DNS… karena akan mereka inject. Who knows, right?
Anyway, gue rasa setiap ISP pasti melakukan DPI. Setiap perusahaan yang menawarkan infrastruktur internet mungkin lebih tepatnya.
Jika DPI adalah sesuatu yang menjadi perhatian lo, let’s talk about so-called VPN.
Internet Packet, but encrypted
Oke daritadi udah banyak menyebutkan terkait “paket” atau yang lebih spesifiknya “internet packet”, jadi, apa sebenarnya itu?
Gue berusaha keras untuk tidak membahas dari Layer 1 sampai Layer 7 di model OSI secara mendetail, dan semoga tidak mengecewakan, ya.
Pertama, kita ke layer 1 dulu: Physical Layer.
Sederhananya ini adalah Network Interface Card (NIC) yang ada di perangkat kita. Ketika komputer 1 dan 2 ingin bisa saling berkomunikasi, maka 2 komputer tersebut harus saling terhubung melalui sebuah media. Nah, penghubung tersebut adalah NIC, dan medianya mungkin bisa Router, Hub, Switch, Bluetooth, apapun. Jika pernah mendengar tentang “Kabel sepaksi/coaxial” atau jenisnya yang biasa disebut “RJ45”, nah si RJ45 ini berada di Layer 1. Lanjut.
Kedua, layer 2: Data Link Layer. Setiap NIC pasti memiliki alamat Medium Access Control (MAC) yang unik setiap perangkatnya meskipun dapat dimanipulasi juga. Alamat MAC ini biasa disebut dengan Ethernet hardware address juga, dan in most scenario kita tidak perlu berurusan langsung dengan Layer 2 ini. Di layer ini, singkatnya, ini adalah tentang bagaimana satu perangkat berkomunikasi dengan perangkat lainnya. Contoh, Address Resolution Protocol (ARP) yang bertugas untuk menanyakan alamat IP x dimiliki oleh alamat MAC apa.
Sekarang layer 3: Network Layer, ini adalah tentang apa yang perangkat tersebut komunikasikan, termasuk melakukan penerusan paket & peruteannya. Contoh, seringkali kita melakukan perintah ping(8) untuk memastikan komputer dengan alamat IP x hidup (atau setidaknya mau diajak berkomunikasi).
Perintah ping mengirim paket menggunakan protokol ICMP, pengirim mengetahui harus kemana paket tersebut dikirim (setelah melakukan ARP) lalu router meneruskannya ke tujuan, dan tujuan akan mengirim kembali ke router yang dilanjutkan dengan meneruskannya lagi ke pengirim tersebut.
Selain itu, hal yang terlibat di layer 3 ini juga antara lain IP (IPv4 dan IPv6), IGMP, dan IPSec.
Lanjut, sekarang ke layer 4: Transport Layer. Di layer ini singkatnya bertanggung jawab untuk komunikasi ujung ke ujung dari sebuah jaringan dan yang mentenagai layer diatasnya dari layer 5-7. Jika pernah mendengar terkait TCP dan UDP, mereka berada di layer ini.
Dan karena layer 5 & 6 tidak terlalu penting (Session & Presentation Layer) kita lanjut ke layer 7 yakni Application Layer.
Mari kita mengambil contoh yang paling populer di layer 7 ini: HTTP.
HTTP menggunakan TCP sebagai transport layer, dan untuk membuat “hubungan” di TCP di antar perangkat, ada 3 langkah yang harus dilakukan terlebih dahulu atau yang biasa disebut dengan three way handshake (SYN, SYN ACK, ACK).
Setelah handshake tersebut selesai, barulah pertukaran informasi terjadi. TCP Handshake ini berguna untuk memastikan bahwa mereka membuat hubungan yang stabil sebagaimana “fitur“ dari protokol TCP tersebut.
Baiklah, gue rasa cukup perkenalannya.
Sekarang mari kita bahas tentang paket ini.
Ketika gue mengakses ifconfig.me (HTTP), ada setidaknya 10 pertukaran paket yang terjadi antara komputer gue (192.168.8.187) dan server ifconfig.me (34.117.59.81):
Di paket tersebut, ada 2 jenis yakni Ethernet frame (source MAC & destination MAC) dan IP packet yang terdiri dari protokol, source IP, destination IP, source port, dan destination port.
Dari segi pengguna, kita hanya bisa melihat bahwa source MAC address nya adalah komputer kita dan destination MAC address nya adalah MAC address nya router.
Dan untuk IP packet, source IP nya adalah alamat IP private kita dan destination IP nya adalah alamat IP dari si ifconfig.me yang didapat dari hasil proses melakukan DNS query. Untuk source port, itu menggunakan port random yang digunakan ketika proses handshake sebelumnya, dan destination port tentu saja 80 karena kita menggunakan HTTP, kan?
Bagian menariknya ada di Layer 7, yakni di HTTP.
Ketika gue mengakses ifconfig.me, setidaknya ada 4 “request header” yang gue kirim ke server ifconfig.me:
Method + Path + Versi HTTP (“GET” + “/” + “HTTP/1.1”)
Host: nama ataupun “virtual” host tujuan (ifconfig.me)
User-Agent (curl, misalnya)
Accept (tipe konten yang si klien/user-agent mengerti)
Berdasarkan permintaan diatas, maka server ifconfig.me akan mengirim ACK yang dilanjutkan dengan mengirim “response” nya, yakni “response header” dan “body”.
Nah, karena menggunakan HTTP, 4 data diatas dapat diketahui oleh siapapun yang berada di 1 jaringan, dan data yang paling menarik hanyalah di bagian “Host” dan “Path”. Dan karena dapat diketahui, berarti… yaa dapat dimodifikasi juga, kan?
Bila menggunakan HTTPS, setidaknya ada 21 pertukaran paket yang terjadi dan ada 2 handshake yang dilakukan: TCP Handshake (SYN ACK) dan TLS Handshake (Client & Server Hello). Singkatnya, di TLS Handshake ini mereka saling bertukar versi TLS yang digunakan; cipher yang didukung, validasi sertifikat server, dan menentukan “random” seed.
Apa yang mereka bicarakan yang pihak ketiga (ISP misalnya) ketahui hanya 3:
Method (CONNECT)
Host (ifconfig.me)
Protocol (HTTP/1.1)
That’s it.
Namun masih ada 1 celah (terkait privasi) disini yang nanti akan kita bahas disesi berbeda: Host (hostname) leak. Celah ini bisa ditutupi dengan Encrypted Server Name Indication (ESNI) alias Encrypted Client Hello (ECH) yang beberapa klien/peramban sedang terapkan, termasuk di Firefox. Namun itu di pembahasan lain, oke?
Lalu, mana bagian “paket ter-enkripsi” nya?
Oke, sebelumnya, masih ingat kan tentang layer 3 yang tentang “perutean” dan “penerusan” paket? Rute yang dimaksud adalah seperti ini:
Jika diilustrasikan, kurang lebih seperti ini:
Kunci nya adalah ada di gateway.
Ketika kita melakukan permintaan ke ifconfig.me, komputer kita akan mengirim paket ke server yang memiliki alamat IP 34.117.59.81, dan karena di routing table tidak ada rute untuk 34.117.59.0/32 secara eksplisit (actually ke 34.64.0.0/10), berarti akan diteruskan ke default alias gateway (0.0.0.0/0 sederhananya seperti “catch-all” atau wildcard).
Kasus encrypted packet pertama misal melakukan DNS Query. Gue personally tidak bisa memverifikasi keabsahannya karena data nya encrypted, tapi kita bisa melihat ke “sequence number” yang ada di pojok kiri tangkapan layar berikut:
Disitu terlihat bahwa gue melakukan DNS query untuk dns.quad9.net ke server yang memiliki alamat IP 100.107.188.120 (private tailscale), urutannya adalah:
100.107.147.55 (ip private tailscale laptop gue) mengirim paket DNS ke 100.107.188.120 (ip private tailscale dns server gue)
192.168.8.187 (ip private laptop gue dari router) mengirim paket Wireguard ke 128.199.89.41 (server gue juga, cuman gue setting sementara buat ngatur dns di demo ini)
100.107.188.120 memberikan response terkait paket DNS tadi ke 100.107.147.55
128.199.89.41 memberikan response terkait paket Wireguard yang entah apa ke 192.168.8.187
Jika penasaran paket dari router nya seperti apa, kurang lebih seperti ini:
Yeah, tidak ada yang tau paket apa itu kecuali si komputer pemilik IP 100.107.147.55 yang mana adalah komputer gue sendiri hahaha semenjak paket tersebut end-to-end encrypted. Ilustrasinya kurang lebih seperti ini:
Berdasarkan dari ilustrasi tersebut, deep packet inspection (ataupun injection) relatif sulit dilakukan, karena sederhananya tidak mengetahui jenis paket (HTTP? HTTPS? DNS? ICMP?). Namun paket tersebut diketahui adalah protokol Wireguard, dan jika Wireshark saja sadar, apalagi program khusus untuk melakukan DPI.
…tinggal blokir paket yang menggunakan protokol Wireguard, selesai.
Penyedia layanan VPN pada dasarnya hanya melakukan 2 hal:
Membuat tunnel dari klien ke VPN server
Rute semua paket via tunnel (VPN client), enkripsi, teruskan ke gateway yang mengarah ke VPN server.
That’s it.
Pembeda paling kontras dari layanan VPN yang ada hanyalah ketersediaan data center dan kecepatan VPN server tersebut dalam memproses dan meneruskan paket karena bukankah encryption costs CPU tasks a lot, right?
Penyedia VPN tentu saja akan mengetahui alamat IP (public) yang diberikan ISP untuk kamu, dan jika niat tracking, sesederhana mapping data pengguna dengan alamat IP publik tersebut atau the worst dengan public key jika penyedia VPN tidak memberikan pilihan untuk rotation.
Penutup
Kesimpulan: Ya, paket yang ter-enkripsi bisa mencegah DPI.
Namun bisa dengan mudah juga men-drop paket tersebut jika ISP yang kamu gunakan banyak gaya seperti Indi****Home.
Internet pada dasarnya hanyalah tentang komputer yang saling terhubung & berkomunikasi, tentang perutean paket, dan tentang penerusan paket.
Tujuan gue dari membuat menyediakan layanan edgyDNS adalah untuk agar terlindung dari DPI untuk permintaan DNS query yang paket nya by design tidak ter-enkripsi. Dan edgyDNS menyediakan 3 protokol sebagai first-class:
HTTPS
TLS
QUIC
Yang mana 3 protokol diatas menggunakan enkripsi dalam komunikasinya. Yang sederhananya, ISP (atau siapapun yang ada di jaringan kamu) tidak mengetahui apakah komputer kamu melakukan DNS query (ataupun sedang menonton film) karena sederhana: paket yang dikirim dalam bentuk ter-enkripsi.
Selain edgyDNS, edgy.network juga menyediakan edgyPROXY via SOCKS5 dan SOCKS5 over QUIC. Dengan tujuan yang hampir sama, namun semua paket yang kamu kirim diteruskan ke proxy server via tunnel serta dns query dilakukan di proxy server.
Dan tentu saja penerusan paket tersebut ter-enkripsi.
Sebagai penutup, tidak ada yang salah dengan DPI, bisa saja server edgy.network gue terapkan DPI juga.
Namun yang pasti, paket berada dalam bentuk ter-enkripsi.
Ya, gue tau kalau ada pengguna dengan alamat IP 112.x.x.x menggunakan edgyDNS ataupun edgyPROXY, untuk pertanyaan apakah pengguna tersebut mengakses github.com? pornhub.com? netflix.com? trakteer.id/evilfactorylabs?
I don’t know, karena data dalam bentuk ter-enkripsi.
Dan gue tidak peduli juga.
ISP mungkin bisa saja mematuhi peraturan pemerintah tanpa harus melakukan DPI dengan cara meng-enkripsi paket pelanggannya dengan cara, misalnya, membuat SDN yang pelanggannya harus pasang—yang tentu saja hampir tidak mungkin.
Bagaimanapun, pemblokiran tidak akan pernah menjadi solusi yang efektif.
Blokir port 41641 untuk protokol UDP? Masih ada 666,666 port lain yang bisa digunakan.
Blokir akses ke vimeo.com? Damn, you know the answer, right?
Se-level Great Firewall nya China aja bisa di bypass, apalagi cuman sekadar mesin pemblokir seharga 1 triliyun rupiah ;)
Anyway, jika hal-hal terkait DPI ini menjadi masalah untuk kamu, bisa pertimbangkan menggunakan layanan yang ada di edgy.network. Dan jika kamu tertarik dengan konten-konten seperti ini, silahkan klik tombol Subscribe untuk selalu mendapatkan kabar terbaru.
See you in the next hop!