SSL/TLS: Kenapa Ada Gembok di Browser dan Gimana Cara Kerjanya

Kenapa HTTP Itu Bahaya?

HTTP (Hypertext Transfer Protocol) itu plaintext. Artinya data yang dikirim antara browser dan server ga dienkripsi sama sekali.

Siapa aja yang bisa "menguping" koneksi kamu — ISP, admin WiFi, hacker di kafe — bisa baca:

• Username dan password yang kamu ketik
• Nomor kartu kredit
• Pesan pribadi
• Cookie session (bisa dipakai buat hijack akun)

sequenceDiagram
    participant U as User
    participant A as Attacker (Man-in-the-Middle)
    participant S as Server

    U->>A: Login: user=budi, pass=rahasia123
    Note over A: Baca semua data! 👀
    A->>S: Login: user=budi, pass=rahasia123
    S-->>A: Welcome, Budi! (+ session cookie)
    A-->>U: Welcome, Budi!

Ini disebut Man-in-the-Middle (MITM) attack. Dan dengan HTTP, ini trivially mudah dilakukan.

HTTPS memecahkan masalah ini.

SSL vs TLS: Bedanya Apa?

SSL (Secure Sockets Layer) dan TLS (Transport Layer Security) itu basically hal yang sama — protokol untuk mengenkripsi koneksi.

Timeline:

• SSL 1.0 (1994) — ga pernah dirilis publik (terlalu banyak bug)
• SSL 2.0 (1995) — dirilis, banyak vulnerability
• SSL 3.0 (1996) — improvement, tapi akhirnya juga vulnerable (POODLE attack)
• TLS 1.0 (1999) — "SSL 3.1", pengganti SSL
• TLS 1.1 (2006) — minor improvement
• TLS 1.2 (2008) — standar yang dipakai most of internet
• TLS 1.3 (2018) — versi terbaru, lebih cepat dan lebih aman

SSL udah deprecated sejak 2015. Yang kita pakai sekarang itu TLS. Tapi orang masih bilang "SSL" karena kebiasaan — kayak orang masih bilang "save" pakai ikon floppy disk. 💾

Jadi kalau kamu baca "SSL certificate," itu sebenarnya TLS certificate. Istilah "SSL" dipake karena branding.

Gimana HTTPS Bekerja?

HTTPS = HTTP + TLS. TLS itu layer enkripsi yang duduk di antara HTTP dan TCP.

graph TB
    subgraph HTTPS
        HTTP[HTTP - Application Data]
        TLS[TLS - Encryption Layer]
        TCP[TCP - Transport]
        IP[IP - Network]
    end
    HTTP --> TLS --> TCP --> IP

Sebelum data HTTP dikirim, browser dan server harus negosiasi enkripsi dulu. Proses ini disebut TLS Handshake.

TLS Handshake (TLS 1.2)

Ini bagian paling penting. TLS Handshake itu proses di mana browser dan server:

1. Setuju mau pakai algoritma apa
2. Verifikasi identitas server (pakai sertifikat)
3. Generate shared encryption key

sequenceDiagram
    participant C as Client (Browser)
    participant S as Server

    Note over C,S: 1. Client Hello
    C->>S: Supported TLS versions, cipher suites, client random

    Note over C,S: 2. Server Hello
    S->>C: Chosen TLS version, cipher suite, server random

    Note over C,S: 3. Certificate
    S->>C: Server certificate (public key)

    Note over C,S: 4. Client verifikasi certificate
    C->>C: Cek certificate chain, expiry, domain

    Note over C,S: 5. Key Exchange
    C->>S: Pre-master secret (encrypted with server public key)

    Note over C,S: 6. Both generate session key
    C->>C: Session key = f(client random, server random, pre-master)
    S->>S: Session key = f(client random, server random, pre-master)

    Note over C,S: 7. Finished
    C->>S: Encrypted "finished" message
    S->>C: Encrypted "finished" message

    Note over C,S: ✅ Komunikasi terenkripsi dimulai!

Step by step:

1. Client Hello

Browser kirim ke server:

• Versi TLS yang didukung (TLS 1.2, TLS 1.3)
• Cipher suites yang didukung (daftar algoritma enkripsi)
• Client random — angka random 32 byte

2. Server Hello

Server pilih:

• Versi TLS yang akan dipakai
• Cipher suite yang dipilih dari daftar client
• Server random — angka random 32 byte

3. Certificate

Server kirim sertifikat digital yang berisi:

• Public key server
• Domain yang tertulis di sertifikat
• Siapa yang menerbitkan (Certificate Authority)
• Masa berlaku

4. Client Verifikasi Certificate

Browser cek:

• Certificate expired belum?
• Domain di certificate cocok sama domain yang diakses?
• Certificate ditandatangani oleh CA yang dipercaya?
• Certificate ada di revocation list?

Kalau gagal → browser tampilin warning "Your connection is not private."

5. Key Exchange

Client generate pre-master secret (angka random), encrypt pakai public key dari sertifikat server, lalu kirim ke server.

Hanya server yang bisa decrypt ini karena hanya server yang punya private key.

6. Generate Session Key

Baik client maupun server punya tiga komponen:

• Client random
• Server random
• Pre-master secret

Ketiganya dimasukkan ke fungsi yang sama dan menghasilkan session key yang identik di kedua sisi. Session key ini yang dipakai untuk enkripsi semua data selanjutnya.

7. Symmetric Encryption Dimulai

Setelah session key dibuat, semua komunikasi di-encrypt pakai symmetric encryption (AES). Kenapa ga pakai asymmetric terus?

Karena asymmetric encryption (RSA) itu lambat. Symmetric encryption (AES) itu ratusan kali lebih cepat. Jadi:

• Asymmetric cuma dipake di awal buat tuker kunci secara aman
• Symmetric dipake untuk enkripsi data selanjutnya

Best of both worlds.

TLS 1.3: Lebih Cepat

TLS 1.2 handshake butuh 2 round trip (bolak-balik) sebelum data bisa dikirim. TLS 1.3 memotong ini jadi 1 round trip.

graph LR
    subgraph TLS 1.2
        A1["Client Hello"] --> B1["Server Hello + Cert"] --> C1["Key Exchange"] --> D1["Finished"]
        Note1["2 round trips"]
    end

graph LR
    subgraph TLS 1.3
        A2["Client Hello + Key Share"] --> B2["Server Hello + Cert + Finished"]
        Note2["1 round trip"]
    end

Perubahan utama di TLS 1.3:

• 1-RTT handshake — client langsung kirim key share di Client Hello
• 0-RTT resumption — kalau udah pernah connect, bisa kirim data di request pertama (tapi ada risiko replay attack)
• Hapus cipher suite yang lemah — ga support RSA key exchange, RC4, SHA-1, dll
• Forward secrecy wajib — selalu pakai Diffie-Hellman (ECDHE)

Sertifikat Digital

Apa itu Sertifikat?

Sertifikat digital itu KTP-nya server. Berisi:

• Public key server
• Domain yang dilindungi
• Identitas pemilik (opsional, tergantung tipe)
• Masa berlaku
• Signature dari Certificate Authority

Certificate Authority (CA)

CA itu pihak ketiga yang dipercaya untuk menerbitkan dan memverifikasi sertifikat.

Browser punya daftar CA yang dipercaya (root store). Kalau sertifikat ditandatangani oleh CA yang ada di daftar ini, browser percaya.

CA terkenal: Let's Encrypt, DigiCert, Comodo, GlobalSign, Sectigo.

Chain of Trust

Sertifikat ga langsung ditandatangani oleh Root CA. Ada hierarchy:

graph TB
    Root["Root CA Certificate<br/>(DigiCert Root)"]
    Inter["Intermediate CA Certificate<br/>(DigiCert SHA2)"]
    Leaf["Leaf Certificate<br/>(www.example.com)"]
    
    Root -->|signs| Inter
    Inter -->|signs| Leaf

• Root CA: jumlahnya sedikit, sangat dijaga. Private key-nya disimpan offline
• Intermediate CA: perantara. Kalau intermediate compromised, bisa di-revoke tanpa ganti root
• Leaf Certificate: sertifikat server kamu

Browser verifikasi dari bawah ke atas: leaf → intermediate → root. Kalau chain valid sampai root yang dipercaya → ✅

Tipe Sertifikat

DV itu yang paling cepat (bisa dapet dalam menit) dan biasanya gratis dari Let's Encrypt. OV dan EV butuh proses manual dan berbayar.

Wildcard dan SAN

• Wildcard certificate: *.example.com — cover semua subdomain satu level (www.example.com, api.example.com, tapi bukan dev.api.example.com)
• SAN (Subject Alternative Name): satu sertifikat bisa cover multiple domain (example.com, example.org, api.example.com)

Cipher Suite

Cipher suite itu paket algoritma yang dipakai selama koneksi TLS. Namanya keliatan rumit:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Tapi bisa dipecah:

TLS 1.3 menyederhanakan ini. Cipher suite di TLS 1.3:

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256

Lebih sedikit pilihan = lebih sedikit kemungkinan salah konfigurasi.

Forward Secrecy

Masalah tanpa Forward Secrecy

Misalkan server pakai RSA key exchange:

1. Client encrypt pre-master secret pakai RSA public key server
2. Server decrypt pakai RSA private key

Kalau 5 tahun kemudian private key server bocor, attacker yang sudah merekam traffic lama bisa:

1. Decrypt pre-master secret dari recording
2. Derive session key
3. Decrypt semua data lama

Semua komunikasi yang pernah terjadi jadi bisa dibaca. Ini disebut retrospective decryption.

Solusi: Ephemeral Key Exchange (DHE/ECDHE)

Dengan Diffie-Hellman Ephemeral (DHE) atau Elliptic Curve DHE (ECDHE):

• Setiap koneksi generate key pair baru yang sifatnya sementara
• Setelah session selesai, ephemeral key dibuang
• Private key server bocor? Ga bisa decrypt session lama karena ephemeral key-nya udah ga ada

Ini disebut Perfect Forward Secrecy (PFS). TLS 1.3 mewajibkan ini.

Let's Encrypt dan ACME

Dulu, sertifikat SSL itu mahal ($100-$1000/tahun) dan prosesnya manual. Ini bikin banyak website ga pakai HTTPS.

Let's Encrypt (2015) mengubah ini:

• Gratis — sepenuhnya free
• Otomatis — pakai ACME protocol untuk issue dan renew otomatis
• Open — transparansi penuh

ACME Protocol

ACME (Automatic Certificate Management Environment) itu protokol untuk otomasi:

1. Client (misal Certbot) minta sertifikat ke Let's Encrypt
2. Let's Encrypt kasih challenge — buktiin kamu punya domain
3. Challenge bisa: taruh file di /.well-known/acme-challenge/ (HTTP-01) atau bikin DNS TXT record (DNS-01)
4. Let's Encrypt verifikasi challenge
5. Sertifikat diterbitkan (valid 90 hari)
6. Certbot otomatis renew sebelum expired

# Install certbot dan dapet sertifikat
sudo certbot --nginx -d example.com -d www.example.com

# Auto-renewal sudah di-setup otomatis
sudo certbot renew --dry-run

Common Mistakes

1. Mixed Content

Halaman HTTPS tapi load resource (gambar, script, CSS) via HTTP.

<!-- ❌ Mixed content -->
<img src="http://example.com/image.jpg">
<script src="http://cdn.example.com/app.js"></script>

<!-- ✅ Selalu pakai HTTPS atau protocol-relative -->
<img src="https://example.com/image.jpg">
<script src="//cdn.example.com/app.js"></script>

Browser modern block mixed content. Halaman keliatan broken.

2. Certificate Expired

Sertifikat punya masa berlaku. Expired = browser tampilin warning = user kabur.

Solusi: auto-renewal (Certbot) dan monitoring expiry date.

# Cek expiry dari command line
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

3. Ga redirect HTTP ke HTTPS

Punya HTTPS tapi HTTP masih bisa diakses tanpa redirect. User yang ketik example.com (tanpa https://) masuk ke versi HTTP.

# Nginx: redirect semua HTTP ke HTTPS
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Tambahkan HSTS header supaya browser ingat dan otomatis pakai HTTPS:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

4. Cipher suite yang lemah

Masih support cipher suite lama yang vulnerable:

• RC4 — broken
• DES/3DES — weak
• MD5/SHA-1 — collision attacks

Solusi: konfigurasi server untuk cuma terima cipher suite yang kuat. Cek di ssl-labs.com untuk audit.

5. Self-signed certificate di production

Self-signed certificate itu sertifikat yang kamu tandatangani sendiri — ga ada CA yang verifikasi. Browser ga percaya.

Boleh dipake untuk development/internal. Jangan pake di production — user bakal lihat warning dan kabur.

Ringkasan

Kesimpulan

SSL/TLS itu fondasi keamanan internet modern. Tanpa ini, semua data kita terbang di udara dalam plaintext.

Yang perlu diingat:

1. HTTPS bukan opsional — ini wajib. Google bahkan kasih ranking boost untuk HTTPS
2. TLS 1.3 itu standar — lebih cepat (1-RTT), lebih aman, forward secrecy wajib
3. Let's Encrypt bikin ga ada alasan untuk ga pakai HTTPS — gratis dan otomatis
4. Certificate chain itu penting — kalau intermediate missing, koneksi bisa gagal
5. Forward secrecy lindungi data masa lalu — walaupun private key bocor nanti
6. Selalu test — pakai SSL Labs untuk cek konfigurasi

Gembok di browser itu kecil, tapi ada banyak engineering di baliknya. Dan sekarang kamu tahu gimana cara kerjanya.