Hari ini saya catat topik yang selama ini saya pakai setiap hari tanpa benar-benar paham isinya: HTTPS. Gembok di browser itu artinya apa, siapa yang menjamin identitas server, dan apa yang sebenarnya terjadi di balik layar sebelum halaman pertama termuat. Ternyata jawabannya ada di protokol bernama TLS, dan sebagai programmer yang tiap hari ngoprek web, ini wajib saya pahami bukan cuma sebagai simbol “aman”, tapi sebagai mekanisme nyata.
HTTPS = HTTP yang masuk terowongan
HTTP biasa mengirimkan permintaan dan respons dalam bentuk teks polos — siapa pun yang berada di tengah jalur (WiFi kafe, ISP, router) bisa membacanya. HTTPS menambahkan lapisan TLS di atas HTTP. Analogi sederhananya: surat biasa vs surat yang dimasukkan ke amplop tersegel, lalu dikirim lewat kurir yang identitasnya disertifikat resmi. Isinya tidak berubah, tapi tidak ada yang bisa membaca atau mengubahnya di jalan tanpa ketahuan.
Menariknya, TLS tidak hanya mengenkripsi. Tiga janjinya sejalan dengan CIA triad yang saya catat di episode #1: confidentiality (isi pesan rahasia), integrity (di jalan tidak ada yang menyisipkan atau mengubah data), dan authentication (kamu yakin sedang bicara dengan server yang benar, bukan peniru).
Handshake TLS 1.3: empat langkah, satu round-trip
Versi TLS yang berlaku sekarang adalah 1.3, distandardisasi lewat RFC 8446 (Agustus 2018). Kalau di TLS 1.2 handshake-nya bisa makan dua round-trip (beberapa bolak-balik sebelum data boleh dikirim), TLS 1.3 mampet jadi satu. Urutan singkatnya seperti di gambar di atas:
- ClientHello — browser mengirim daftar versi dan cipher suite yang didukung, plus sebuah kunci publik sementara.
- ServerHello + sertifikat — server memilih cipher, mengirim kunci publiknya sendiri, dan menyertakan sertifikat sebagai bukti identitas.
- Key exchange — kedua belah pihak menghitung kunci rahasia yang sama secara lokal. Kunci privat tidak pernah dikirim lewat jaringan sama sekali.
- Data terenkripsi — semua trafik berikutnya dienkripsi dengan kunci session itu.
Yang saya garis bawahi: kunci privat tidak pernah melintas jaringan. Keduanya hanya bertukar bahan mentah (kunci publik), lalu menghitung kunci session masing-masing. Karena kunci session dibuat baru tiap koneksi (ephemeral), TLS 1.3 punya sifat perfect forward secrecy — meski kunci privat server besok bocor, trafik hari ini tetap tidak bisa dibuka.
Ada satu fitur kecepatan bernama 0-RTT: klien boleh menempelkan data di flight pertama tanpa menunggu. Tapi RFC 8446 sendiri memperingatkan data 0-RTT lemah secara keamanan — tidak forward secret dan tidak ada jaminan anti-replay, artinya request yang sama bisa diulang penyerang. Pelajarannya bagi saya: kecepatan selalu punya harga, dan protokol yang baik menuliskan batasnya di spesifikasi, bukan menyembunyikannya.
Sertifikat: siapa yang menjamin “ini benar server-nya”
Gembok di browser muncul karena server mengirim sertifikat, dan sertifikat itu ditandatangani oleh Certificate Authority (CA) yang sudah dipercaya sistem kamu. Rantai kepercayanya mirip dompet digital: paspor diterbitan negara, negara dipercaya karena ada perjanjian internasional. Kalau server meniru identitas situs lain, signature tidak cocok dan browser langsung menolak.
Untuk server kecil, Let’s Encrypt membuat sertifikat gratis lewat protokol ACME dengan validasi otomatis. Yang menarik dari perkembangan terbaru: sejak 15 Januari 2026, Let’s Encrypt umumkan ketersediaan umum sertifikat jangka pendek 6 hari (160 jam). Logikanya begini — kalau kunci privat server bocor, sertifikat lama (90 hari) bisa terus dipakai penyerang sampai kedaluwarsa selama mekanisme pencabutan (revocation) yang historisnya tidak andal tidak bekerja. Sertifikat 6 hari memperpendek jendela paparan drastis, dengan catatan renewal harus otomatis. Let’s Encrypt juga menegaskan masa depannya: masa berlaku default akan turun dari 90 ke 45 hari dalam beberapa tahun ke depan. Bagi saya ini sinyal jelas — otomasi sertifikat bukan lagi pilihan, tapi prasyarat.
Versi lama sudah dimatikan — jangan sampai server kita nyangkut
TLS 1.0 (1999) dan 1.1 (2006) resmi didepresiasi RFC 8996 (2021), dan peramban besar sudah mematikan dukungannya jauh sebelum itu: Chrome 84 dan Edge 84 (Juli 2020), Firefox 74 (Maret 2020), serta Safari di rilis macOS/iOS 2020. Artinya kalau server kita masih menawarkan TLS 1.0, peramban modern tidak akan mau konek — dan kalau masih bisa konek, itu justru bendera merah.
Di Nginx, membatasi versi semudah ini:
server {
listen 443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
}Setelah mengubah konfigurasi, saya selalu verifikasi ulang pakai pemeriksa eksternal (misalnya SSL Server Test Qualys) supaya yakin tidak ada jalur TLS lama yang masih terbuka lewat proxy atau CDN di depan server.
HSTS: memaksa jalur aman
HTTPS saja belum cukup kalau user masih bisa mengetik http:// di address bar — ada jendela pertama yang masih polos. HTTP Strict Transport Security (HSTS, RFC 6797) menyuruh browser: “untuk domain ini, selalu pakai HTTPS, jangan pernah coba HTTP lagi selama X waktu”. Header-nya sederhana, dan ada opsi daftar preload agar perlakuannya berlaku bahkan untuk kunjungan pertama.
Di episode #11 kita sudah bahas session dan cookie — di sini nyambung langsung: cookie login harus selalu punya flag Secure agar hanya dikirim lewat HTTPS, dan HttpOnly agar tidak bisa diintip skrip. Tanpa HTTPS yang benar-benar dipaksa, dua flag itu tidak ada artinya.
Checklist praktis yang saya catat
Dari belajar hari ini, ini daftar yang saya pegang untuk proyek sendiri: minimal TLS 1.2, prioritaskan 1.3; sertifikat gratis dari Let’s Encrypt dengan auto-renew; aktifkan HSTS setelah yakin seluruh aset sudah HTTPS (hati-hati — preload sulit ditarik mundur); set flag Secure + HttpOnly pada cookie sensitif; dan pantau lewat tools eksternal, bukan cuma klaim dari dalam server. TLS mengajarkan saya satu hal: keamanan transport bukan soal enkripsi semata, tapi soal bukti identitas, integritas, dan keputusan sadar mematikan yang lama.
Episode berikutnya kita masuk ke kriptografi dasar — symmetric vs asymmetric, hash, dan digital signature yang selama ini jadi pondasi diam-diam dari semua yang kita bahas hari ini.
Sumber
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3: rfc-editor.org/rfc/rfc8446
- RFC 8996 — Deprecating TLS Versions 1.0 and 1.1: rfc-editor.org/rfc/rfc8996
- RFC 6797 — HTTP Strict Transport Security (HSTS): rfc-editor.org/rfc/rfc6797
- Let’s Encrypt — “6-day and IP Address Certificates are Generally Available” (15 Januari 2026): letsencrypt.org
- MDN Web Docs — HTTPS: developer.mozilla.org
- Qualys SSL Labs — SSL Server Test: ssllabs.com
Komentar Terbaru