Sudah sekitar 25 tahun HTTPS dibuat oleh Netscape Communications, HTTPS pada dasarnya adalah layer tambahan untuk HTTP: HTTP yang Secure. Karena pada protokol HTTP, data yang ditukar tidak ter-enkripsi.

Yang berarti, seseorang yang berada dijaringan yang sama–khususnya di public wifi–mereka bisa melihat lalu lintas data yang sedang berjalan.

Masalah pada protokol HTTP bukan hanya terhadap kebocoran informasi, melainkan di keamanan. Seseorang bisa menginjeksi data yang dikirim ataupun diterima sebelum data tersebut sampai ke "tujuan" yang sebenarnya.

Yang biasa disebut dengan Man In The Middle Attack (MITM).

Dengan menggunakan lapisan tambahan–Transport Layer Security (TLS)–penyerangan ini bisa dicegah, karena data yang diminta dan diterima tidak sama alias rusak sejak komunikasi yang terjadi menggunakan enkripsi.

Enkripsi secara singkat

Koneksi adalah tentang pertukaran informasi, menggunakan "bahasa" yang dimengerti oleh satu-sama lain agar informasi yang dikirim dan diterima dapat dipahami maksudnya.

Seperti, jika saya berkata "Selamat pagi" kepada orang Indonesia, mereka (kemungkinan) akan menjawab "Selamat pagi juga". Karena mereka mengetahui dan mengerti dari maksud yang saya katakan.

Beda ketika saya bilang "hatur nuhun" kepada orang Bali misalnya, yang kurang familiar dengan bahasa Sunda. Mereka mungkin tidak mengerti apa yang saya maksud, dan tidak tau apa yang harus mereka jawab.

Kita ambil contoh dari kasus hatur nuhun, intinya yang ingin saya sampaikan adalah "berterima kasih". Enkripsi adalah tentang menyamarkan informasi, yang membutuhkan public dan private key dalam melakukan penyamarannya.

Namun dalam konteks diatas, kita hanya butuh private key. Yang berarti, enkrispi yang dilakukan adalah secara simetris, dan bergantung dengan private key. Dalam kasus ini, private key tersebut adalah bahasa Sunda. Jika orang tau kalau itu bahasa Sunda (tau private key nya), berarti dia akan tau isi dari informasi yang sudah disamarkan tersebut.

Enkripsi beda dengan hashing yang untuk mengetahui "data aslinya" harus dilakukan dengan cara menebak paksa (brute force, mencocokkan hash) dan juga beda dengan encoding yang mana encoding hanya mengandalkan "pola" yang digunakan untuk menyamarkan informasi.

Contoh:

> Hash (MD5)

"eff5bc1ef8ec9d03e640fc4370f5eacd" == "ok"

bisa dicek dengan melakukan test satu2 berdasarkan
kata yang sudah dikumpulkan dan terdapat kata "ok"
dalam kumpulan kata (kamus) tersebut

> Encoding (Base64): "b2s=" == "ok"

menggunakan radix 64 untuk transformasinya

> Enkripsi (Blowfish): "U2FsdGVkX18T8yR6McZdMbwog34DmS+1" == "ok"

menggunakan password (pada kasus ini "r") dan teknik
blowfish untuk transformasinya. Yang berarti,
salah teknik/salah password berarti gak akan
bisa melihat data asilnya.

try it: echo "U2FsdGVkX18T8yR6McZdMbwog34DmS+1" | openssl enc -d -bf -a

Di protokol HTTPS, enkripsi terjadi secara simetris dan asimetris yang akan kita bahas secara detailnya.

SYN-ACK secara singkat

HTTP adalah layer diatas TCP/IP, dan untuk bisa membuat komunikasi, client perlu mengirim paket bertipe SYN (Synchronization) yang nantinya server akan membalasnya dengan SYN-ACK (Syncrhonization Acknowledged), yang mana ACK tersebut akan digunakan untuk request selanjutnya dari client.

Paket tersebut adalah sebuah angka, yang mana disetiap pengiriman-dan-penerimaan nya angka bertambah 1 nilainya. Ilustrasi sederhananya seperti ini:

  1. Client meminta request, mengirim paket SYN dengan nilai 1337
  2. Server menerima request, mengirim paket SYN dengan nilai 666 dan ACK dengan nilai 1338
  3. Client melakukan request, lalu mengirim paket ACK dengan nilai 667.

Proses diatas dinamakan 3 Way Handsake, yang berguna untuk membuat proses komunikasi lancar.

Kita perlu membahas SYN-ACK/3 handshake ini karena ketika menggunakan HTTPS kita perlu melakukan TLS Handshake.

Enkripsi simetris & asimetris secara singkat

Tadi kita sudah menyinggung bahwa enkripsi yang dilakukan di HTTPS ada 2: Simetris dan Asimetris. Kita sudah membahas singkat tentang enkripsi yang dilakukan secara simetris, disini kita akan membahas secara singkat enkripsi simetris & asimetris yang dilakukan di protokol ini.

Asimetris

Untuk proses enkripsi secara asimetris, kita perlu menggunakan public & private key. Pengirim mengirim data ke penerima berdasarkan public key yang dimiliki oleh penerima tersebut, dan penerima bisa men-decrypt data tersebut berdasarkan private key yang dia miliki.

Public & private key disini ada di server penerima, dan dibuat ketika situs ingin menggunakan protokol HTTPS saat pertama kali setup.

Enkripsi secara asimetris disini digunakan untuk membuat "pre-master" key: Client mengirim pre-master key ke server berdasarkan public key server, lalu server men-decrypt nya dengan private key dia. Berdasarkan pre-master key tersebutlah dibuat master key yang digunakan untuk berkomunikasi antar client dan server.

Simetris

Ingat kan kalau enkripsi secara simetris membutuhkan sebuah "password"? Password tersebut dibuat setelah enkripsi secara asimetris diatas terjadi (berdasarkan pre-master key). Dan proses pemembuatan password tersebut ("master key") dilakukan oleh client dan server.

Jadi, ketika client misal mengirim request dengan hex dump seperti ini:

0000000 55 32 46 73 64 47 56 6b 58 31 2f 50 6e 4b 36 77
0000010 6b 6d 41 5a 42 7a 76 2f 34 67 67 64 6e 4a 51 64
0000020 2b 75 57 6b 55 66 41 37 36 70 45 64 49 4d 42 45
0000030 39 64 30 73 65 76 2b 4c 79 51 70 6b 67 67 58 4d
0000040 0a 42 70 56 72 76 6a 6c 49 75 4c 41 3d 0a
000004e

Server bisa melakukan dekripsi dari request yang ter-enkripsi tersebut menggunakan master key yang ada.

Perintah kedua sebagai contoh bagaimana server "membaca" request yang ter-enkripsi tersebut karena dia tau passwordnya (master key). Begitupula dengan client yang menerima response dari server, client (komputer dia) tau cara membaca data yang ter-enkripsi tersebut.

TLS Handshake secara singkat

Untuk membuat master key tersebut, perlu dilakukannya proses TLS Handshake. Dan pembeda antara HTTP dan HTTPS secara high-level ada diproses ini.

Perintah pertama ketika koneksi menggunakan protokol HTTPS, dan yang dibawah ketika menggunakan protokol HTTP. Terdapat tambahan 83ms dalam waktu client menerima response dari server, namun 83ms bukanlah masalah yang besar, bukan?

Kita tidak akan bahas banyak tentang TLS Handshake disini, karena pada dasarnya hampir sama dengan yang dibagian SYN-ACK diatas. Ini kondisi ketika client "tidak percaya" bahwa response tersebut datang nya dari server yang dimaksud.

Familiar? Intinya, client (browser/Firefox) tidak percaya dengan sertifikat yang diterima karena Firefox tidak yakin kalau sertifikat tersebut valid untuk domain tersebut (akan dibahas selengkapnya nanti).

Baik, bagaimana bila tidak menggunakan protokol HTTPS?

https://evilfactorylabs.org :)

Dan ini halaman yang seharusnya diterima:

https://unikom.ac.id

Karena singkatnya, client langsung percaya dengan response yang diterima dari request tersebut.

Disclaimer: This case just for example purpose and visible only on my machine.

High-level View

Mari kita bahas secara detail dari bagian yang lebih global.

Untuk menggunakan protokol HTTPS, port yang digunakan adalah 443. Syaratnya, pemilik domain harus membuat sertifikat tersebut dan "ditanda tangani" oleh stakeholder yang terpecaya: Browser vendor.

Bagaimana bila kita membuat sertifikat yang kurang terpercaya (alias ditanda-tangani "sendiri")? Bisa, tapi muncul warning seperti diatas. Namun tetap bisa diakses kalau memang si client tidak peduli dengan pesan tersebut.

Yang menerbitkan sertifikat tersebut bukanlah browser, melainkan "entitas lain yang dipercaya browser". Misal, Comodo CA. Atau Let's Encrypt. Jika browser percaya dengan entitas tersebut, maka sertifikat tersebut besar kemungkinan valid.

Prosesnya, pemilik domain melakukan permintaan untuk penerbitan sertifikat. Lalu, penertbit melakukan "challenge" salahsatunya untuk memvalidasi kepemilikan domain (misal disuruh membuat file di path X dengan konten Y). Jika oke, penerbit akan memberikan sertifikatnya (public & private key) yang akan digunakan untuk membuat "master key" dalam proses koneksi yang ter-enkripsi secara simetris tersebut.

Ini contoh public key yang diterbitkan oleh Let's Encrypt (via Traefik), sertifikat disimpan di file json dengan format yang sudah di encode menggunakan base64.

Kurang lebih konten dari public key/private key (sertifikat) yang ada dimulai dengan baris -----BEGIN CERTIFICATE--— seperti yang ada diatas.

Ada beberapa penerbit yang menerbitkan sertifikat nya dengan fitur tambahan agar situsnya terlihat lebih terpercaya, ini salah satunya adalah Medium menggunakan Digicert (pembedanya adalah warna gemboknya berwarna hijau bila di Safari), yang bila dilihat detail sertifikatnya, di sertifikat tersebut ada detail informasi lengkap (nama perusahaan, lokasinya, dll)

Dari sisi pemilik domain, yang harus dilakukan hanyalah meminta penerbit sertifikat untuk membuatkan sertifikat HTTPS (pub & priv key) untuk domain kita, entah itu menggunakan layanan gratis (via Let's Encrypt, go donate!) atau berbayar (Digicert, Comodo CA, dll).

Untuk Let's Encrypt, proses bisa diautomasi entah menggunakan certbot ataupun Traefik.

Penutup

Motivasi menulis ini adalah tentang membahas seputar HTTPS dari sudut pandang yang sedikit teknis, beda dengan yang biasa dibahas oleh perusahaan hosting™ yang kebanyakan membahas sisi bisnis™ nya.

"Secure" di HTTPS adalah tentang enkripsi, dan enkripsi akan selalu berurusan dengan kriptografi.

Selalu ada biaya di kriptografi, pada konteks disini adalah di latensi round trip: Menambah sekian milidetik untuk response time dari server. Banyak keuntungan yang didapat dari menggunakan protokol HTTPS ini (daripada kerugiannya), silahkan bisa baca-baca disini.

Kita akan mebahas seputar HSTS secara detail di post selanjutnya, intinya, terima kasih telah mampir! And yes, your site should use HTTPS.