HTTPS adalah HTTP yang dibungkus TLS (Transport Layer Security), lapisan yang mengenkripsi data antara browser dan server. Tanpa HTTPS, semua yang dikirim, termasuk password dan cookie, bisa dibaca siapa saja yang satu jaringan denganmu, misalnya di WiFi kafe. Bayangin mengirim kartu pos: tukang pos dan siapa pun yang memegangnya bisa membaca isinya. HTTPS mengubah kartu pos itu jadi surat di dalam amplop tersegel yang cuma bisa dibuka penerima yang benar.
🧪 Tebakan cepat: sebuah URL dimulai dengan
http://(tanpa s). Aman untuk mengirim password lewat URL itu, atau gak? Dan URL yang dimulaiftp://, masuk kategori apa: secure, insecure, atau invalid? Tebak dulu, jawabannya ada di bagian "Mengenali URL yang aman".
Tiga hal yang dijamin TLS
TLS memberi tiga jaminan sekaligus di tiap koneksi:
- Kerahasiaan (enkripsi): data diacak, jadi orang di tengah cuma melihat sampah. ISP atau hacker di WiFi gak bisa membacanya.
- Integritas: data gak bisa diubah diam-diam di jalan. Kalau satu byte berubah, browser tahu dan menolaknya.
- Autentikasi: server membuktikan dirinya memang
bank.example, bukan penyamar. Ini bagian certificate.
Selain itu, fitur browser modern seperti service worker dan geolocation cuma jalan di HTTPS, dan Google memprioritaskan situs HTTPS di hasil pencarian.
TLS 1.3 handshake: menyepakati kunci sebelum bertukar data
Sebelum data pertama dikirim, browser dan server melakukan handshake: perkenalan singkat untuk menyepakati kunci rahasia bersama. Versi terbaru, TLS 1.3, menyelesaikannya dalam satu putaran (1-RTT, satu kali pulang-pergi). Di Lab, handshake ke bank.example berjalan langkah demi langkah:
| Langkah | Arah | Isi |
|---|---|---|
| 1. ClientHello | browser ke server | versi TLS 1.3, daftar cipher, dan key share browser |
| 2. ServerHello | server ke browser | cipher yang dipilih, dan key share server |
| 3. Certificate | server ke browser | certificate bank.example, ditandatangani CA |
| 4. Verify + Finished | browser lalu server | browser cek certificate, kedua pihak hitung session key, lalu saling kirim Finished |
| 5. Application data | dua arah | semua data dienkripsi dengan session key |
- ClientHello sudah membawa "key share": angka publik untuk menghitung kunci bersama. Ini yang bikin TLS 1.3 cepat; di TLS 1.2 ini butuh putaran tambahan.
- ServerHello memilih cipher dan mengirim key share server. Dari dua key share ini, kedua pihak menghitung session key yang sama, tanpa pernah mengirim kunci itu sendiri. Pola ini namanya key exchange (ECDHE).
- Certificate membuktikan server benar-benar
bank.example. Browser mengeceknya di langkah verify. - Setelah Finished, semua data (langkah 5) dienkripsi dengan session key. Dari sini seterusnya pakai enkripsi simetris (satu kunci yang sama), karena jauh lebih cepat dari enkripsi dengan key exchange tadi.
Jadi TLS memakai dua jenis enkripsi: key exchange (asymmetric) cuma untuk menyepakati kunci di awal, lalu simetris untuk semua data sesudahnya.
Kunci yang dipakai di key exchange dibuat baru tiap koneksi dan dibuang setelah handshake (ephemeral). Ini memberi Perfect Forward Secrecy (PFS): kalau private key server bocor di masa depan, session yang lama tetap gak bisa dibuka, karena kuncinya sudah dibuang.
Certificate dan rantai kepercayaan
Certificate adalah kartu identitas digital server. Isinya nama domain (bank.example), public key server, masa berlaku, dan tanda tangan dari penerbitnya. Penerbitnya disebut Certificate Authority (CA): pihak yang dipercaya browser.
Browser gak percaya certificate bank.example begitu saja. Dia mengikuti rantai sampai ke akar yang sudah dia percaya:
bank.example (leaf: certificate situsnya)
ditandatangani oleh
R3 / intermediate CA (certificate perantara)
ditandatangani oleh
ISRG Root X1 (root CA, sudah ada di browser)
- Leaf adalah certificate situs. Ditandatangani oleh intermediate, bukan langsung root.
- Intermediate menjembatani leaf dan root. Server mengirim leaf + intermediate; root sudah ada di dalam browser.
- Root ada di daftar bawaan browser/OS. Kalau rantai sampai ke root yang dipercaya, certificate valid. Kalau putus di tengah atau sampai ke root yang gak dikenal, browser menolak dan menampilkan peringatan.
Browser juga menolak kalau nama domain gak cocok, certificate kedaluwarsa, atau tanda tangannya gak sah. Certificate gratis bisa didapat dari Let's Encrypt, biasanya lewat Certbot, dan diperbarui otomatis.
HSTS: memaksa HTTPS
Walau situs sudah HTTPS, kunjungan pertama kadang masih lewat http:// sebelum dialihkan. Header HSTS menutup celah itu: browser diminta mengingat untuk selalu pakai HTTPS ke domain ini.
Strict-Transport-Security: max-age=31536000; includeSubDomains
max-age=31536000berarti ingat selama satu tahun (dalam detik).includeSubDomainsmemberlakukan aturan ini ke semua subdomain juga.- Setelah header ini diterima sekali, browser otomatis mengubah
http://jadihttps://sendiri, tanpa sempat mengirim request yang gak aman.
Mengenali URL yang aman
Ini pengecekan sederhana yang membedakan tiga jenis URL dari protocol-nya:
function isSecureURL(url) {
const lower = url.toLowerCase(); // cek case-insensitive
if (lower.startsWith("https://")) return "secure";
if (lower.startsWith("http://")) return "insecure";
return "invalid"; // bukan http/https
}
console.log(isSecureURL("https://example.com")); // secure
console.log(isSecureURL("http://example.com")); // insecure
console.log(isSecureURL("ftp://files.com")); // invalid
toLowerCase()dulu, supayaHTTPS://juga dikenali. Pengecekan string peka huruf besar-kecil.https://di depan berarti aman: ada TLS.http://berarti gak aman: polos, bisa dibaca di jalan.- Yang gak dimulai dengan salah satunya (
ftp://,mailto:) bukan HTTP sama sekali:"invalid".
| Panggilan | Hasil |
|---|---|
isSecureURL("https://example.com") |
"secure" |
isSecureURL("http://example.com") |
"insecure" |
isSecureURL("ftp://files.com") |
"invalid" |
isSecureURL("HTTPS://SECURE.COM") |
"secure" |
isSecureURL("mailto:[email protected]") |
"invalid" |
Jadi http:// itu "insecure": jangan kirim password lewat sana. ftp:// itu "invalid". Itu jawaban tebakannya.
⚠️ Jebakan yang sering ketemu
- Lupa
toLowerCase().isSecureURL("HTTPS://...")jadi"invalid"karenastartsWith("https://")peka huruf. Samakan dulu ke huruf kecil. - Mengira
http://cukup di localhost tapi lupa produksi. Di produksi semua harus HTTPS, dan semuahttp://dialihkan kehttps://. - Mengabaikan peringatan certificate. Peringatan "certificate tidak valid" sering berarti ada yang menyadap atau certificate kedaluwarsa. Jangan di-klik-terus begitu saja.
- Menyamakan HTTPS dengan "situs aman". HTTPS cuma menjamin koneksinya terenkripsi. Situs phishing pun bisa punya HTTPS. HTTPS bukan cap bahwa situsnya jujur.
TL;DR: HTTPS adalah HTTP di atas TLS, yang menjamin kerahasiaan, integritas, dan autentikasi. Handshake TLS 1.3 selesai satu putaran: ClientHello dan ServerHello bertukar key share untuk menghitung session key bersama, server mengirim certificate, lalu semua data dienkripsi simetris. Certificate mengikuti rantai dari leaf ke intermediate ke root yang dipercaya browser; certificate gratis dari Let's Encrypt. Header HSTS (Strict-Transport-Security) memaksa browser selalu pakai HTTPS. isSecureURL mengembalikan "secure" untuk https://, "insecure" untuk http://, "invalid" untuk yang lain, dan samakan ke huruf kecil dulu.
