Belajar Wget - HTTPS, TLS & Certificates

#Pendahuluan

Di episode 12 kalian mengendalikan jalur jaringan — proxy, protokol IP, bind address, dan DNS. Sekarang wget tahu kemana paket harus pergi. Pertanyaan berikutnya jauh lebih penting: dengan siapa kalian sebenarnya berbicara? Ketika wget menembak https://, ada satu lapisan yang bekerja sebelum satu byte HTTP pun berpindah — lapisan itu adalah TLS.

Bayangkan mengirim surat penting lewat kantor pos umum. Amplop bisa disegel, tapi siapa yang menjamin ia sampai ke alamat yang benar dan tidak dibuka di tengah jalan? TLS menjawab dua hal sekaligus: enkripsi (tidak ada yang bisa membaca isi) dan otentikasi (kalian yakin lawan bicara adalah server yang sebenarnya). Episode 13 membedah lapisan keamanan yang paling sering dianggap remeh ini.

#HTTPS: HTTP di Dalam Tunnel TLS

HTTPS bukan protokol ajaib yang baru — ia HTTP yang berjalan di dalam tunnel TLS. Sebelum request dikirim, wget dan server melakukan handshake TLS: bertukar parameter, menyepakati versi protokol, memverifikasi identitas, lalu membangun kunci enkripsi sesi. Setelah tunnel terbentuk, HTTP berjalan normal di dalamnya, tidak terlihat oleh siapa pun di tengah jalan.

Cek dulu bahwa build wget kalian punya dukungan TLS:

wget --version

Perhatikan bagian akhir output yang menyebut OpenSSL atau GnuTLS. Hampir semua distribusi modern memilikinya, tapi build yang sangat minimalis kadang tidak — dan tanpa dukungan TLS, seluruh https:// tidak akan pernah berfungsi.

#Verifikasi Sertifikat Secara Default

Inti otentikasi TLS adalah sertifikat digital — dokumen yang diterbitkan oleh Certificate Authority (CA), pihak yang dipercaya untuk "membubuhkan tanda tangan" atas identitas server. wget, jika dibangun dengan dukungan SSL, memverifikasi sertifikat secara default: memeriksa bahwa rantai sertifikat berujung pada CA yang dipercaya sistem, bahwa masa berlaku masih aktif, dan bahwa nama host cocok dengan yang tertera di sertifikat. Ini analog dengan kartu identitas — kalian tidak pernah bertemu penerbitnya, tapi karena tanda tangannya bisa diverifikasi sampai ke institusi yang kalian percaya, kartunya dipercaya.

Jika verifikasi gagal, wget menolak sebelum mengirim data apa pun, dengan pesan seperti ini:

ERROR: cannot verify example.com's certificate, issued by 'CN=...':
  Unable to locally verify the issuer's authority.
To connect to example.com insecurely, use '--no-check-certificate'.

Perhatikan yang paling penting: wget menolak sebelum satu byte pun terkirim, dan keluar dengan exit code 5 (SSL verification failure). Itu bukan bug — itu fitur. Data kalian tidak pernah dikirim ke pihak yang tidak terverifikasi.

#CA Bundle dan --ca-certificate

Verifikasi default memakai kumpulan CA yang diinstal di sistem. Untuk lingkungan khusus — CA internal perusahaan, server staging, atau jaringan terisolasi — kalian bisa menunjuk bundle atau direktori tertentu:

wget --ca-certificate=/etc/ssl/certs/ca-certificates.crt \
  https://api.internal.example.com/

wget --ca-directory=/etc/ssl/certs https://api.internal.example.com/

--ca-certificate menunjuk satu file bundle; --ca-directory menunjuk direktori berisi banyak sertifikat. Pendekatan paling bersih tetap menginstal CA internal ke direktori sistem dengan update-ca-certificates, sehingga wget memercayainya tanpa flag tambahan di setiap script.

#--secure-protocol: Mengunci Versi TLS

TLS punya beberapa generasi, dan tidak semuanya pantas dipakai. Versi lawas seperti SSLv2, SSLv3, dan TLS 1.0 sudah dianggap usang dan hampir selalu ditolak server modern — di banyak build terbaru bahkan sudah dihapus dari OpenSSL. Opsi --secure-protocol mengunci versi yang boleh dipakai:

wget --secure-protocol=TLSv1_2 https://api.example.com/

wget --secure-protocol=TLSv1_3 https://api.example.com/

Nilai yang sah antara lain auto (default, memilih terbaik), TLSv1_2, dan TLSv1_3. Jika kalian menunjuk protokol yang tidak didukung build, wget menolak dengan pesan bahwa protokol tidak tersedia — pilihan yang justru menyehatkan, karena kalian ingin tahu kebijakan macet daripada diam-diam turun ke versi lemah. Menetapkan TLSv1_2 atau TLSv1_3 secara eksplisit menghapus ambiguitas di lingkungan dengan kebijakan keamanan yang ketat.

#Mengapa --no-check-certificate Berbahaya

--no-check-certificate mematikan verifikasi sertifikat. Ini cara tercepat membuat error di atas hilang — dan juga cara tercepat membuka pintu untuk man-in-the-middle. Tanpa verifikasi, siapapun di jalur jaringan — ISP, proxy yang tidak jujur, atau penyerang di wifi publik — bisa menyisipkan sertifikat palsu dan membaca seluruh isi transfer seolah-olah mereka server asli.

# JANGAN lakukan ini di produksi
wget --no-check-certificate https://api.example.com/secure

Bayangkan mengunci pintu depan lalu memberikan kunci ke semua orang di jalan. --no-check-certificate persis seperti itu: enkripsinya tetap ada, tapi penguncinya dibagikan ke siapa saja. Kalau sebuah endpoint memaksa kalian memakai opsi ini, pertanyaan yang benar bukan "bagaimana mematikan verifikasi?", melainkan "kenapa server ini tidak punya sertifikat yang valid?".

#Sertifikat Klien: Mutual TLS

Verifikasi sejauh ini hanya satu arah — client memverifikasi server. Ada skema yang lebih ketat, mutual TLS (mTLS), di mana server juga memverifikasi client. Server meminta client membuktikan identitasnya dengan sertifikat klien. wget mengirimkannya lewat --certificate dan --private-key:

wget --certificate=client.pem --private-key=client-key.pem \
  https://api.example.com/secure

• --certificate=client.pem — sertifikat klien (identitas + kunci publik).
• --private-key=client-key.pem — kunci privat pasangannya.

Jika kunci privat terenkripsi, wget meminta passphrase secara interaktif. Bila formatnya DER dan bukan PEM, tunjukkan lewat --certificate-type=DER dan --private-key-type=DER. mTLS dipakai untuk komunikasi service-to-service yang ketat — antar microservice, atau koneksi dari CI ke registry internal. Identitas bisa diperiksa di kedua arah, dan itu kekuatan sekaligus tanggung jawab: kunci privat yang bocor adalah kartu identitas yang bisa dipalsukan.

#HSTS: Memaksa HTTPS

Ada lubang halus di HTTPS: koneksi pertama ke sebuah situs masih bisa jatuh ke HTTP jika penyerang memotongnya lebih dulu — serangan yang dikenal sebagai downgrade di kunjungan pertama. HSTS (HTTP Strict Transport Security) menutup lubang itu. Ketika server menjawab dengan header Strict-Transport-Security, wget mencatat host tersebut dan untuk jangka waktu tertentu otomatis mengupgrade http:// menjadi https://:

wget --hsts-file=$HOME/.wget-hsts https://example.com/

File HSTS database disimpan di lokasi yang kalian tunjuk — defaultnya ~/.wget-hsts — dan opsi --no-hsts mematikan seluruh mekanisme ini. Ini seperti seorang satpam yang mencatat: "mulai sekarang, ke gedung ini wajib lewat koridor terenkripsi." HSTS mengubah keputusan satu kali menjadi kebijakan yang diingat — pertahanan berlapis di atas verifikasi sertifikat biasa.

#Penutup

Episode 13 membuka kap mesin lapisan keamanan HTTPS di wget: memahami bahwa HTTPS adalah tunnel TLS di atas HTTP, verifikasi sertifikat CA yang aktif secara default dan exit code 5 saat gagal, mengendalikan CA bundle dengan --ca-certificate dan --ca-directory, mengunci versi TLS dengan --secure-protocol, menghindari --no-check-certificate karena alasan yang kuat, mengirim sertifikat klien dengan --certificate dan --private-key untuk mutual TLS, serta memanfaatkan HSTS untuk memaksa HTTPS.

Inti yang perlu diingat: verifikasi sertifikat bukan formalitas — ia identitas yang bisa diperiksa. Mematikan verifikasi tidak membuat masalah hilang; ia hanya menyembunyikannya di bawah karpet, dan siapapun yang lewat bisa mengambil data kalian.

Di episode 14 berikutnya kita menutup lingkaran keamanan dari sisi yang berbeda: autentikasi dan best practice keamanan — bagaimana menyimpan kredensial agar tidak bocor lewat shell history, peran file .netrc, dan checklist yang wajib dijalani setiap download. Sampai jumpa!