Belajar Remote Desktop - Enkripsi VNC (TLS/SSL & VNC Encryption)
Episode 13 of 23

Belajar Remote Desktop - Enkripsi VNC (TLS/SSL & VNC Encryption)

Episode ini mengatasi kelemahan terbesar VNC: tanpa enkripsi semua data terkirim plaintext dan bisa disadap. Kalian akan mengaktifkan TLS/SSL di x11vnc dan TigerVNC, melihat bukti sadapan dengan tcpdump, dan memahami SSH tunnel sebagai lapis enkripsi.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

Episode 12 memperkuat autentikasi, tapi ada satu lubang yang lebih besar: VNC tanpa enkripsi mengirim semua data sebagai plaintext. Layar kalian, input keyboard, dan handshake autentikasi melewati jaringan dalam bentuk yang bisa dibaca siapa pun yang menyadap. Di jaringan publik atau WiFi terbuka, ini sama dengan mengirim isi layar ke sembarang orang.

Episode 13 menutup lubang itu. Kalian akan melihat sendiri bukti sadapan dengan tcpdump, mengaktifkan enkripsi TLS/SSL di x11vnc dan TigerVNC, serta memahami posisi SSH tunnel sebagai lapis enkripsi terakhir yang akan dibahas tuntas di episode 14.

Masalah Keamanan VNC Plaintext

Apa yang Bocor Tanpa Enkripsi

Ketika viewer terhubung ke server VNC tanpa enkripsi, semua komunikasi RFB melintas mentah di jaringan. Data yang bocor mencakup:

  • Handshake autentikasi: challenge-response DES yang bisa ditangkap dan di-brute-force secara offline.
  • Framebuffer layar: setiap piksel yang dikirim server ke viewer bisa disadap.
  • Input keyboard dan mouse: setiap ketikan dan klik kalian ikut terbaca.

Inilah alasan VNC mentah tidak boleh dibuka ke internet. Di jaringan lokal internal pun, kebiasaan menyadap masih relevan — terutama di lingkungan dengan banyak pengguna.

Membuktikan Sadapan dengan tcpdump

Cara paling meyakinkan adalah melihat sendiri. Jalankan tcpdump di satu mesin, lalu buka sesi VNC, dan amati data yang lewat:

Menangkap lalu lintas VNC
sudo tcpdump -i eth0 -X -s 0 port 5900

Perintah sudo tcpdump -i eth0 -X -s 0 port 5900 menangkap paket di port 5900 dan menampilkannya dalam bentuk hex dan ASCII. Jika kalian memperhatikan, bagian header protokol RFB terlihat jelas sebagai teks terbaca — bukti bahwa tidak ada enkripsi di lapisan ini.

Warning

Setelah percobaan, tutup sesi tanpa enkripsi dan aktifkan salah satu mekanisme di bawah ini. Menyadap lalu lintas sendiri untuk belajar itu sah, tapi membiarkan VNC terbuka plaintext di jaringan publik adalah risiko yang tidak perlu diambil.

Enkripsi x11vnc dengan -ssl

Membuat Sertifikat dan Mengaktifkan SSL

x11vnc mendukung enkripsi TLS/SSL bawaan. Dengan opsi -sslgen, x11vnc membuat sertifikat self-signed secara otomatis dan langsung menggunakannya:

Aktifkan SSL di x11vnc
x11vnc -display :0 -ssl -sslgen -rfbauth /etc/x11vnc.pass

Perintah x11vnc -display :0 -ssl -sslgen -rfbauth /etc/x11vnc.pass menjalankan server dengan koneksi yang dienkripsi TLS. Untuk sertifikat dari CA resmi — yang tidak memicu peringatan di viewer — buat sertifikat dengan openssl lalu tunjukkan lewat -sslcert:

Generate sertifikat dengan openssl
openssl req -x509 -newkey rsa:2048 -keyout /etc/x11vnc-key.pem -out /etc/x11vnc-cert.pem -days 365 -nodes
x11vnc -display :0 -ssl /etc/x11vnc-cert.pem -rfbauth /etc/x11vnc.pass

Koneksi dari Viewer yang Mendukung TLS

Viewer TigerVNC bisa terhubung ke server TLS dengan memilih security type yang sesuai:

Viewer ke server SSL
vncviewer -SecurityTypes TLSVnc,TLSNone 192.168.1.20:5900

Enkripsi TigerVNC dengan TLS

Memilih Security Type

TigerVNC (terutama 1.16 ke atas) membangun dukungan TLS berbasis GnuTLS. Server memilih mekanisme lewat opsi -SecurityTypes, dan viewer wajib menyepakati mekanisme yang sama:

Server TigerVNC dengan TLS
Xvnc :1 -geometry 1920x1080 -depth 24 -SecurityTypes VncAuth,TLSVnc -passwordfile ~/.vnc/passwd

Perintah Xvnc :1 -SecurityTypes VncAuth,TLSVnc -passwordfile ~/.vnc/passwd membuat display :1 yang menerima koneksi VNC dengan autentikasi password yang dienkripsi TLS. Di sisi viewer:

Viewer memaksa TLS
vncviewer -SecurityTypes TLSVnc localhost:5901

Jika server dan viewer memakai security type yang tidak cocok, koneksi gagal dengan pesan yang menunjukkan daftar mekanisme yang didukung masing-masing pihak.

Memeriksa Dukungan Build

Tidak semua build TigerVNC menyertakan TLS. Verifikasi dukungannya dengan perintah berikut:

Cek dukungan TLS viewer
vncviewer --help | grep -i -E "security|tls"

Output yang menampilkan opsi -SecurityTypes menandakan build viewer mendukung TLS. Jika tidak ada, upgrade TigerVNC ke 1.16 atau gunakan SSH tunnel sebagai gantinya.

SSH Tunnel sebagai Lapis Enkripsi

Enkripsi Penuh Tanpa Konfigurasi Server

Cara paling universal dan dapat diandalkan adalah membungkus VNC dengan SSH tunnel. Keunggulannya: tidak perlu mengubah konfigurasi server sama sekali, enkripsi ditangani OpenSSH yang sudah teruji, dan server bisa tetap terikat ke localhost.

Tunnel SSH untuk VNC
ssh -L 5901:localhost:5900 arman@192.168.1.20

Setelah tunnel aktif, viewer di mesin lokal cukup terhubung ke localhost:5901 dan seluruh lalu lintas VNC melewati koneksi SSH yang terenkripsi:

Viewer lewat tunnel
vncviewer localhost:5901

Pola inilah yang paling dianjurkan untuk akses VNC dari jaringan luar, dan episode 14 akan membahasnya secara menyeluruh — termasuk jump host dan reverse tunnel.

Penutup

Episode 13 menutup kelemahan VNC plaintext: kalian melihat bukti sadapan dengan tcpdump, mengaktifkan TLS/SSL di x11vnc dengan -sslgen, memakai security type TLS di TigerVNC, dan mengenali SSH tunnel sebagai lapis enkripsi paling universal.

Inti yang harus dibawa pulang:

  • VNC tanpa enkripsi mengirim layar, input, dan handshake sebagai plaintext.
  • tcpdump -X port 5900 membuktikan header RFB bisa dibaca langsung.
  • x11vnc memakai -ssl dan -sslgen untuk TLS/SSL bawaan.
  • TigerVNC memakai -SecurityTypes VncAuth,TLSVnc untuk TLS.
  • Viewer dan server harus menyepakati security type yang sama.
  • SSH tunnel adalah lapis enkripsi paling universal tanpa ubah server.

Di episode 14 selanjutnya kita membedah SSH tunneling dan remote access yang aman — local forward untuk VNC dan RDP, tunnel dua arah untuk bypass firewall, jump host dengan ssh -J, serta reverse tunnel agar server di belakang NAT bisa diakses dari luar. Sampai jumpa!