Pada episode ini kita akan memahami verifikasi sertifikat TLS yang aktif secara default, mengarahkan bundle CA internal dengan ca-certificate, menghindari opsi yang mematikan pemeriksaan sertifikat, serta menjalani checklist keamanan: sumber terpercaya, verifikasi checksum, dan validasi file BitTorrent maupun metalink.

Di episode 12 kalian mengendalikan jalur jaringan — proxy, interface, bind address, dan DNS. Sekarang aria2 tahu kemana paket harus pergi. Pertanyaan berikutnya jauh lebih penting: dengan siapa kalian sebenarnya berbicara? Ketika aria2 menembak https://, ada satu lapisan yang bekerja sebelum satu byte 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, ditutup dengan kebiasaan verifikasi yang menyelamatkan kalian dari drama yang tidak perlu.
HTTPS bukan protokol ajaib yang baru — ia HTTP yang berjalan di dalam terowongan TLS. Sebelum request dikirim, aria2 dan server melakukan handshake TLS: bertukar parameter, menyepakati versi protokol, memverifikasi identitas, lalu membangun kunci enkripsi sesi. Setelah terowongan terbentuk, HTTP berjalan normal di dalamnya, tidak terlihat oleh siapa pun di tengah jalan.
aria2 dibangun di atas perpustakaan TLS (OpenSSL atau GnuTLS tergantung build). Seluruh lapisan ini bekerja tanpa disuruh — tetapi keputusan apakah kalian memercayai hasil verifikasinya ada di tangan kalian.
Inti otentikasi TLS adalah sertifikat digital — dokumen yang diterbitkan oleh Certificate Authority (CA), pihak yang dipercaya untuk membubuhkan tanda tangan atas identitas server. aria2 memverifikasi sertifikat secara default (--check-certificate=true): 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, aria2 menghentikan download sebelum mengirim data apa pun, dengan pesan seperti ini:
Exception: [SslError.cc:...] certificate verification failed:
the peer certificate could not be verified
[ERROR] CUID#7 - Download aborted. URI=https://example.com/...Perhatikan yang paling penting: aria2 menolak sebelum satu byte pun terkirim. Itu bukan bug — itu fitur. Data kalian tidak pernah dikirim ke pihak yang tidak terverifikasi, dan teks persisnya bisa sedikit berbeda antar versi aria2.
--ca-certificate: Memercayai CA InternalVerifikasi default memakai kumpulan CA yang diinstal di sistem. Untuk lingkungan khusus — CA internal perusahaan, server staging, atau jaringan terisolasi — kalian bisa menunjuk bundle yang dipakai:
aria2c --ca-certificate=/etc/ssl/certs/ca-certificates.crt \
https://api.internal.example.com/--ca-certificate=/etc/ssl/certs/ca-certificates.crt menunjuk satu file bundle berisi daftar CA. Pendekatan paling bersih tetap menginstal CA internal ke direktori sistem dengan update-ca-certificates, sehingga aria2 memercayainya tanpa flag tambahan di setiap script — atau taruh opsi ini di aria2.conf agar berlaku untuk semua invocation.
TLS punya beberapa generasi, dan tidak semuanya pantas dipakai. Versi lawas seperti SSLv3 dan TLS 1.0 sudah dianggap usang. Opsi --min-tls-version mengunci ambang bawah yang boleh dipakai, dan untuk komunikasi service-to-service yang ketat aria2 mendukung sertifikat klien:
aria2c --min-tls-version=TLSv1.2 \
--certificate=client.pem --private-key=client-key.pem \
https://api.example.com/secure--min-tls-version=TLSv1.2 — tolak semua handshake di bawah versi ini.--certificate=client.pem — sertifikat klien (identitas + kunci publik).--private-key=client-key.pem — kunci privat pasangannya.Skema ini disebut mutual TLS (mTLS): server juga memverifikasi klien. Identitas bisa diperiksa di kedua arah, dan itu kekuatan sekaligus tanggung jawab — kunci privat yang bocor adalah kartu identitas yang bisa dipalsukan.
--check-certificate=false Berbahaya--check-certificate=false mematikan verifikasi sertifikat. Ini cara tercepat membuat error di atas hilang — dan juga cara tercepat membuka pintu untuk man-in-the-middle. Tanpa verifikasi, siapa pun 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
aria2c --check-certificate=false https://api.example.com/secureBayangkan mengunci pintu depan lalu memberikan kunci ke semua orang di jalan. --check-certificate=false 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?".
Warning
Satu-satunya pengecualian yang bisa diterima: pengujian lokal sesaat terhadap server yang sengaja memakai self-signed certificate untuk development — dan itupun sebaiknya diganti dengan CA internal yang diinstal ke bundle, bukan dengan mematikan verifikasi. Di produksi, --check-certificate=false tidak pernah punya alasan.
Setiap download adalah keputusan: mempercayakan eksekusi atau pemakaian file pada sumber tertentu. Mengunduh biner dari situs tidak resmi seperti mengundang orang asing masuk rumah tanpa memeriksa kartu identitas. Tiga pertanyaan yang selalu layak diajukan:
--check-certificate=false?Important
Dua lini pertahanan terakhir kalian adalah verifikasi sertifikat dan verifikasi checksum. Turunkan salah satunya — mematikan --check-certificate atau mengabaikan checksum — dan seluruh rantai kepercayaan menjadi tebakan.
--checksumDownload yang sukses bukan berarti download yang benar. File bisa rusak di tengah jalan, atau sengaja diganti oleh pihak lain. Karena itu sumber terpercaya mempublikasikan checksum — sidik jari matematis file — yang harus kalian bandingkan setelah download. aria2 punya verifikasi checksum bawaan, tidak perlu tool eksternal:
aria2c --checksum=sha-256=9f2c1a7b4d8e0f3c5a6b7c8d9e0f1a2b3c4d5e6f \
https://example.com/app/app-1.2.3.tar.gz--checksum=sha-256=HASH membandingkan hash file hasil download dengan nilai yang dipublikasikan; jika tidak cocok, aria2 menolak hasilnya. Untuk memverifikasi file yang sudah ada di disk tanpa mengunduh ulang, pakai --hash-check-only=true — kombinasi yang sempurna untuk audit biner yang baru di-copy dari server lain.
Protokol download lain membawa mekanisme integritasnya sendiri — dan mematikannya berarti membuang perlindungan gratis.
.torrent berisi piece hashes untuk setiap potongan konten. Dengan --check-integrity=true, aria2 membandingkan setiap potongan file dengan hash tersebut — wajib diaktifkan saat resume atau verifikasi torrent yang sudah terunduh, karena potongan yang korup akan dideteksi dan diunduh ulang..meta4 menyematkan checksum per piece yang diverifikasi aria2 secara otomatis selama mengunduh. Pastikan file metalink itu sendiri berasal dari sumber resmi, dan verifikasi tanda tangan PGP-nya bila disediakan — checksum membuktikan file tidak berubah, signature membuktikan siapa yang menerbitkannya.aria2c --check-integrity=true file.torrentTip
Mengaktifkan --check-integrity=true untuk torrent yang sudah selesai adalah audit gratis: seluruh konten diverifikasi tanpa mengunduh apa pun, dan potongan yang korup diunduh ulang secara otomatis. Biaya waktu verifikasi jauh lebih kecil daripada risiko memakai file yang diam-diam rusak.
Episode 13 membuka kap mesin lapisan keamanan HTTPS di aria2: HTTPS sebagai terowongan TLS di atas HTTP, verifikasi sertifikat CA yang aktif secara default, mengendalikan CA internal dengan --ca-certificate, mengunci versi TLS dan memakai sertifikat klien untuk mTLS, menghindari --check-certificate=false karena alasan yang kuat, lalu menjalani checklist — sumber terpercaya, verifikasi checksum dengan --checksum, dan validasi BitTorrent maupun metalink.
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 siapa pun yang lewat bisa mengambil data kalian.
Di episode 14 berikutnya kita memindahkan kunci yang sama ke pintu yang berbeda: RPC security & authentication — bagaimana mengamankan daemon RPC aria2 dengan token, user dan password, serta pola eksposur yang benar agar pintu otomasi tetap terkunci. Sampai jumpa!