TLS Adalah: Protokol di Balik HTTPS, Email, dan DNS

Setiap kali Anda membuka situs perbankan atau toko online, ada ikon gembok kecil di sebelah kiri address bar. Hampir semua pengguna internet tahu gembok itu berarti "aman". Jauh lebih sedikit yang tahu nama mesin yang bekerja di baliknya.

Mesin itu bernama TLS. TLS adalah protokol kriptografi yang memungkinkan dua pihak bertukar data tanpa bisa dibaca atau diubah pihak lain di tengah jalan. Dua pihak itu, dalam kasus gembok tadi, adalah browser Anda dan server yang Anda kunjungi. Gabungan protokol web HTTP dengan lapisan pengaman inilah yang kita kenal sebagai HTTPS.

Namun gembok di address bar hanya satu tempat TLS bekerja, dan mungkin bukan yang paling sering Anda sentuh. Protokol yang sama juga berjalan saat server hosting Anda mengirim email, saat ponsel menanyakan alamat IP sebuah domain, atau saat aplikasi menghubungi database di server lain. Artikel ini membahas TLS sebagai protokolnya, bukan sebagai gemboknya.

Apa Itu TLS?

TLS adalah singkatan dari Transport Layer Security. Tugasnya mengubah koneksi jaringan biasa — yang isinya bisa dibaca siapa saja yang mampu mengintip jalurnya — menjadi percakapan tertutup antara dua pihak.

Posisi kerjanya ada di tengah. Di bawahnya ada protokol transport seperti TCP yang memastikan data sampai utuh dan berurutan. Di atasnya ada protokol aplikasi seperti HTTP, SMTP, atau IMAP yang mengurus isi percakapannya. TLS duduk di antara keduanya, dan spesifikasinya hanya menuntut satu hal dari lapisan di bawah: aliran data yang andal dan berurutan.

Justru karena posisinya di tengah itu, TLS tidak peduli isi percakapan yang diamankannya. Melayani HTTP atau SMTP sama saja baginya. Sifat inilah yang membuat satu protokol bisa dipakai ulang di begitu banyak tempat — sesuatu yang akan kita dalami di bagian akhir artikel.

Nama "Transport Layer Security" sendiri agak menyesatkan, dan itu warisan sejarah. Versi pertamanya dulu dikembangkan dengan nama SSL 3.1, lalu diganti sebelum publikasi agar tidak terasosiasi dengan Netscape.

Tiga Jaminan yang Diberikan TLS

Spesifikasi TLS menyebut tiga hal yang dijaminnya. Urutannya mungkin di luar dugaan: autentikasi disebut lebih dulu, bukan enkripsi.

1. Autentikasi (authentication): Sisi server selalu dibuktikan identitasnya, sementara sisi klien bersifat opsional. Inilah yang memastikan Anda terhubung ke server bank, bukan ke penyadap yang menyamar.
2. Kerahasiaan (confidentiality): Data yang dikirim setelah koneksi terbentuk hanya terlihat oleh kedua ujung percakapan. Pihak di tengah jalan hanya melihat aliran byte acak.
3. Integritas (integrity): Data tidak bisa diubah penyerang tanpa ketahuan. Satu bit saja dimodifikasi, penerima langsung mengetahuinya dan menolak data tersebut.

Perlu diperhatikan, ketiga jaminan itu punya batas yang disebutkan spesifikasinya secara terbuka.

TLS tidak menyembunyikan panjang data yang dikirimnya. Penyadap tidak bisa membaca isi percakapan Anda, tetapi tetap bisa melihat berapa besar data yang lewat dan kapan waktunya. Dari pola ukuran dan waktu itu saja, isi percakapan kadang bisa ditebak.

Jabat Tangan TLS: Cara Kerja Sebelum Percakapan

Sebelum satu byte data aplikasi dikirim, kedua pihak menjalani perkenalan singkat yang disebut handshake (jabat tangan). Tujuannya menyepakati dua hal sekaligus: algoritma apa yang akan dipakai, dan kunci rahasia mana yang akan mereka gunakan bersama.

Di sinilah letak persoalan klasik kriptografi. Enkripsi simetris — satu kunci yang sama untuk mengunci dan membuka — sangat cepat, tetapi kedua pihak harus sudah memegang kunci itu sejak awal. Padahal browser Anda dan server tersebut belum pernah bertemu. Enkripsi asimetris memecahkan masalah perkenalan itu, namun terlalu lambat untuk mengangkut seluruh percakapan.

TLS menggabungkan keduanya. Asimetris dipakai sebentar di awal untuk menyepakati kunci sesi, lalu sisa percakapan berjalan dengan simetris yang jauh lebih cepat. Pada TLS 1.3, kesepakatan itu selesai dalam satu kali perjalanan bolak-balik:

Diagram alur TLS handshake antara klien dan server dengan pertukaran kunci dan verifikasi sertifikat.

Spesifikasi TLS 1.3 membagi proses ini menjadi tiga fase berurutan. Key Exchange menyepakati bahan kunci dan parameter kriptografi; setelah fase ini, semua yang lewat sudah terenkripsi. Server Parameters menyampaikan pengaturan tambahan. Authentication membuktikan identitas server lewat sertifikat dan tanda tangan digital.

Pada langkah pertama, klien tidak sekadar menyapa. Ia langsung menyodorkan kunci publik sementara miliknya, sehingga server bisa membalas dengan miliknya sendiri. Dari sepasang kunci sementara itu, kedua pihak menghitung kunci sesi yang identik tanpa pernah mengirimkan kunci tersebut melalui jaringan.

Soal kecepatan, angkanya tidak perlu dibesar-besarkan. TLS 1.3 menghemat tepat satu perjalanan bolak-balik dibanding TLS 1.2 yang membutuhkan dua. Nilai riilnya tergantung pada latensi jaringan Anda — nyaris tidak terasa untuk server satu kota, tetapi jelas terasa untuk koneksi antarbenua.

Sertifikat Tidak Mengenkripsi Apa Pun

Perhatikan sekali lagi urutan di diagram tadi, khususnya langkah nomor 4. Sertifikat dikirim setelah kunci sesi terbentuk. Artinya sertifikat itu sendiri sampai ke browser Anda dalam keadaan sudah terenkripsi.

Ini membalik anggapan yang sangat umum. Banyak yang mengira sertifikat adalah sumber enkripsi — bahwa membeli sertifikat sama dengan membeli enkripsi. Kenyataannya, enkripsi lahir dari pertukaran kunci di langkah 1 dan 2, jauh sebelum sertifikat muncul. Sertifikat hanya menandatangani pertukaran tersebut, agar Anda yakin sedang bertukar kunci dengan pihak yang benar.

Konsekuensinya cukup mengejutkan. Sertifikat self-signed (yang Anda terbitkan sendiri) tetap memberikan enkripsi sekuat sertifikat termahal di pasar. Yang hilang bukan kekuatan sandinya, melainkan jaminan bahwa lawan bicara Anda bukan penyadap yang menyamar. Anda tetap berbicara dalam bahasa sandi yang sempurna — hanya saja dengan orang yang belum tentu Anda kenal.

Karena itulah browser menampilkan peringatan besar untuk sertifikat yang tidak tepercaya, meskipun koneksinya terenkripsi. Peringatan tersebut bukan tentang enkripsi yang lemah, melainkan tentang identitas yang tidak bisa dibuktikan. Spesifikasi TLS pun menegaskannya. Koneksi tanpa autentikasi yang bisa diverifikasi tetap rentan terhadap serangan man-in-the-middle (penyadap yang menyisip di tengah), sehingga tidak boleh dipakai untuk keperluan umum tanpa konfigurasi khusus.

Pembagian peran ini juga menjelaskan kenapa urusan sertifikat punya dunianya sendiri — mulai dari pemilihan jenis, penerbit, sampai masa berlaku. Pembahasan lengkapnya kami tulis terpisah di artikel SSL adalah, termasuk cara memilih dan memasang sertifikat SSL untuk website Anda.

Dari TLS 1.0 ke TLS 1.3: Yang Dibuang, Bukan Ditambah

Perjalanan versi TLS berlangsung lebih dari dua dekade. Berikut ringkasnya:

TLS 1.0 dan 1.1 resmi dilarang pada Maret 2021 melalui RFC 8996. Alasannya teknis: integritas handshake keduanya bergantung pada SHA-1 yang sudah rapuh, keduanya mewajibkan 3DES, dan keduanya belum mengenal enkripsi modern berjenis AEAD.

Yang menarik dari TLS 1.3 bukan apa yang ditambahkannya, melainkan apa yang dibuangnya. Ambil contoh cipher suite (paket algoritma yang dipakai satu koneksi). Spesifikasi TLS 1.2 mencantumkan 37 nama cipher suite; TLS 1.3 memangkasnya menjadi 5. Semakin sedikit pilihan, semakin sedikit pula kombinasi rapuh yang bisa dinegosiasikan penyerang.

Diagram perbandingan TLS 1.2 dan TLS 1.3 dengan panah ke kanan serta pesan lebih sedikit pilihan, lebih sedikit celah.

Pemangkasan paling berdampak adalah dihapusnya static RSA dan Diffie-Hellman statis. Spesifikasinya menyatakan bahwa setelah penghapusan tersebut, semua mekanisme pertukaran kunci berbasis kunci publik kini memberikan forward secrecy. Kompresi juga dibuang, dan seluruh algoritma simetris lama disingkirkan sehingga hanya menyisakan AEAD.

Forward secrecy artinya kunci sesi tidak bisa dipulihkan di kemudian hari, sekalipun kunci privat server bocor. Tanpa sifat ini, penyerang yang sabar bisa merekam trafik terenkripsi Anda hari ini dan menyimpannya bertahun-tahun. Begitu ia berhasil mencuri satu kunci privat, seluruh rekaman masa lalu ikut terbuka. Dengan forward secrecy, setiap sesi memakai kunci sementara sekali pakai.

TLS 1.3 juga memperkenalkan mode 0-RTT, yang memungkinkan klien mengirim data di paket pertama saat menyambung kembali ke server yang pernah dikunjungi. Kecepatannya menggiurkan, tetapi spesifikasinya memberi peringatan tegas. Data 0-RTT tidak memiliki forward secrecy, dan bisa diputar ulang penyerang di koneksi berbeda. Akibatnya konkret: permintaan pembelian barang atau transfer uang bisa terkirim dua kali.

Sejak Juli 2026, spesifikasi TLS 1.3 diperbarui lewat RFC 9846, menggantikan dokumen lama RFC 8446. Pembaruan ini bukan TLS 1.4; dokumennya menyebut dirinya pembaruan minor dengan nomor versi tetap dan kompatibel ke belakang. Perubahannya antara lain melarang negosiasi TLS 1.0 serta 1.1, dan memperluas bahasa pertukaran kunci agar mencakup KEM — pintu masuk untuk kriptografi tahan komputer kuantum. Yang mudah luput, RFC 9846 sekaligus menggantikan RFC 5246, dokumen asli TLS 1.2. Artinya TLS 1.2 kini tidak lagi memiliki spesifikasi yang berdiri sendiri.

Bagaimana adopsinya di lapangan? Menurut survei Qualys SSL Pulse per Juni 2025, TLS 1.3 sudah didukung 75,3% dari 134.380 situs populer yang disurvei, sementara dukungan TLS 1.2 praktis universal di angka 100%. Angka tersebut perlu dibaca dengan catatan tanggalnya, karena survei itu berhenti diperbarui sejak Juni 2025.

TLS Bukan Hanya untuk Website

Inilah bagian yang mengubah cara Anda memandang gembok tadi. Karena TLS tidak peduli isi percakapan yang dibungkusnya, protokol yang sama dipakai ulang di hampir seluruh sudut infrastruktur internet.

Diagram lima kartu berlabel Web, Email, DNS, VPN, dan Database dengan judul Satu protokol, banyak tempat.

Email. Setiap kali server hosting Anda mengirim atau menerima email, TLS ikut bekerja. Port 465 membuka koneksi yang sudah terenkripsi sejak detik pertama, sedangkan port 587 memulai dari koneksi biasa lalu menaikkannya ke terenkripsi lewat perintah STARTTLS. Untuk penerimaan, port 993 (IMAP) dan 995 (POP3) memakai pola terenkripsi penuh yang sama. Cara kerja lengkapnya kami bahas di artikel SMTP adalah.

DNS. Secara bawaan, pertanyaan DNS dikirim dalam teks polos. Siapa pun yang mengintip jaringan bisa melihat domain yang Anda buka, meskipun isi situsnya sudah HTTPS. Dua standar menutup celah ini: DNS over TLS (DoT) di port 853, dan DNS over HTTPS (DoH) di port 443.

Perbedaan keduanya bukan pada kekuatan enkripsi, karena keduanya memakai TLS yang sama persis. Bedanya pada visibilitas jaringan. DoT tetap dikenali sebagai trafik DNS, sehingga admin jaringan masih bisa mengaturnya. DoH melebur dengan trafik web biasa dan nyaris tidak bisa dibedakan. Kalau ponsel Android Anda mengaktifkan Private DNS, itu DoT yang sedang bekerja.

VPN. OpenVPN memakai TLS, tetapi hanya di control channel — jalur yang mengurus autentikasi dan pertukaran kunci. Data Anda sendiri lewat jalur terpisah dengan kunci hasil negosiasi tersebut. Menariknya, VPN modern seperti WireGuard justru tidak memakai TLS sama sekali dan memilih Noise Protocol Framework. Ini bukti bahwa "enkripsi transport modern" tidak otomatis berarti TLS; TLS satu pilihan desain, bukan satu-satunya jalan.

Database. PostgreSQL di port 5432 dan MySQL di port 3306 sama-sama bisa berjalan di atas TLS. Kalau server aplikasi dan server database Anda berada di mesin berbeda, query beserta isinya melintasi jaringan — dan tanpa TLS, semuanya terbaca polos.

QUIC dan HTTP/3. Di sini batas antara "transport" dan "keamanan" sengaja dilebur. Menurut spesifikasinya, TLS tidak berada di atas maupun di bawah QUIC; hubungan keduanya lebih rumit dari itu. QUIC menyediakan aliran data yang andal untuk TLS, sementara TLS menyediakan kunci enkripsi untuk QUIC. Hasilnya, HTTP/3 tidak punya mode tanpa enkripsi sama sekali.

Enkripsi "Kalau Bisa": Rasa Aman yang Menyesatkan

Setelah melihat betapa luas jangkauan TLS, ada satu pola yang perlu Anda waspadai. Pola ini muncul berulang di sistem yang kelihatannya tidak berhubungan, dan sifatnya sama: mencoba mengenkripsi, tetapi menyerah diam-diam kalau gagal.

1. STARTTLS pada email: Koneksi dimulai dalam keadaan polos, lalu naik kelas ke terenkripsi. Penyerang aktif di tengah jalan hanya perlu menghapus tawaran STARTTLS dari server. Kedua pihak lalu mengira lawannya tidak mendukung enkripsi, dan email terkirim polos — padahal keduanya sebenarnya mampu.
2. PostgreSQL dengan sslmode=prefer: Ini nilai bawaan, dan dokumentasi resminya sendiri menyebutnya tidak direkomendasikan. Bahkan nilai require pun hanya menjamin koneksi terenkripsi tanpa memverifikasi sertifikat sama sekali, sehingga tetap terbuka terhadap serangan man-in-the-middle.
3. MySQL dengan pengaturan bawaan: Klien akan mencoba menyambung dengan enkripsi bila server mendukungnya, lalu kembali ke koneksi tanpa enkripsi bila gagal. Tanpa pemeriksaan aktif, Anda tidak akan pernah tahu bedanya.

Tiga sistem yang berbeda, satu penyakit yang identik. Semuanya melindungi Anda dengan baik dari penyadap pasif yang sekadar mendengarkan. Namun tidak satu pun melindungi dari penyerang aktif yang sanggup mengganggu koneksi, karena semuanya bersedia menurunkan standar demi tersambung. Obatnya juga sepola: jangan cukup meminta enkripsi, tetapi paksakan dan verifikasi.

Selain pola tadi, ada dua batas TLS yang jujur perlu Anda ketahui. Pertama, TLS hanya melindungi data saat berpindah. Begitu data mendarat dan tersimpan di server, TLS tidak lagi berperan; pengamanannya menjadi urusan enkripsi penyimpanan. Kedua, seperti disinggung di awal, TLS tidak menyembunyikan ukuran dan waktu trafik Anda.

Rekomendasi Pengaturan TLS

Berikut pengaturan konkret yang bisa langsung Anda terapkan.

1. Aktifkan TLS 1.2 dan 1.3, matikan TLS 1.0 dan 1.1: Dua versi lama sudah dilarang sejak Maret 2021. Karena dukungan TLS 1.2 praktis universal (100% per Juni 2025), mematikan versi lama nyaris tidak berisiko memutus pengunjung.
2. PostgreSQL: pakai sslmode=verify-full: Jangan biarkan di nilai bawaan prefer. Hanya verify-full yang memverifikasi rantai sertifikat sekaligus mencocokkan hostname, dan hanya itu yang benar-benar menutup celah man-in-the-middle.
3. MySQL: aktifkan require_secure_transport: Dengan variabel ini menyala, koneksi tanpa enkripsi akan ditolak dengan error ER_SECURE_TRANSPORT_REQUIRED, bukan diteruskan diam-diam.
4. Email antar-server: pertimbangkan MTA-STS atau DANE: Keduanya menutup celah penurunan STARTTLS, tetapi lewat akar kepercayaan berbeda — MTA-STS bersandar pada Certificate Authority, DANE pada DNSSEC lewat record TLSA. Bila memilih MTA-STS, gunakan mode enforce.
5. Jangan aktifkan 0-RTT untuk permintaan yang punya efek samping: Aman untuk memuat gambar atau CSS. Berbahaya untuk pembayaran, penghapusan data, atau apa pun yang tidak boleh terjadi dua kali.

Untuk memeriksa versi TLS yang aktif di server Anda, jalankan perintah berikut:

openssl s_client -connect namadomain.com:443 -tls1_3

Kalau koneksi berhasil, server Anda sudah mendukung TLS 1.3. Ganti flag menjadi -tls1 untuk memastikan versi lama justru gagal tersambung — kegagalan itulah pertanda pengaturan Anda sudah benar.

Pertanyaan Seputar TLS

Apa kepanjangan TLS? TLS adalah singkatan dari Transport Layer Security, kira-kira berarti "keamanan lapisan transport". Penamaan itu warisan sejarah dan tidak sepenuhnya menggambarkan posisi kerjanya.

Apa bedanya TLS dan SSL? SSL adalah pendahulu TLS yang sudah pensiun sejak akhir 1990-an. Yang berjalan di semua koneksi modern hari ini adalah TLS, sementara istilah "SSL" bertahan karena kebiasaan pasar. Artinya, "sertifikat SSL" yang dijual hari ini secara teknis adalah sertifikat TLS. Pembahasan lengkapnya ada di artikel SSL adalah.

Apa bedanya TLS dan HTTPS? HTTPS adalah HTTP yang berjalan di atas TLS. TLS lapisan pengamannya, HTTP protokol webnya, HTTPS gabungan keduanya. Perbedaan pentingnya: HTTPS khusus untuk web, sedangkan TLS juga mengamankan email, DNS, VPN, dan database.

Apakah TLS 1.3 wajib dipakai? Belum wajib, tetapi sangat dianjurkan. TLS 1.2 masih aman dan didukung 100% situs per Juni 2025. Yang benar-benar wajib adalah mematikan TLS 1.0 dan 1.1. Idealnya server Anda mendukung TLS 1.2 dan 1.3 sekaligus.

Bagaimana cara tahu versi TLS yang dipakai website saya? Tanpa terminal, buka DevTools browser pada tab Security — versi TLS dan cipher suite koneksi berjalan tampil di sana. Alternatifnya, gunakan perintah openssl s_client di atas atau pemindai publik seperti SSL Labs.

Kesimpulan

TLS adalah protokol yang menjamin autentikasi, kerahasiaan, dan integritas komunikasi antara dua pihak di jaringan. Ia bukan produk yang Anda beli — yang Anda beli adalah sertifikat, dan sertifikat itu mengurus identitas, bukan enkripsi. Enkripsinya sendiri lahir dari pertukaran kunci yang terjadi sebelum sertifikat bahkan dikirim.

Dua hal yang layak Anda bawa pulang. Pertama, gembok di address bar hanyalah satu tempat TLS bekerja; protokol yang sama menjaga email, DNS, VPN, dan database Anda setiap hari. Kedua, banyak sistem menerapkan TLS dengan sikap "kalau bisa" — dan sikap itu hanya melindungi dari penyadap yang pasif. Untuk apa pun yang benar-benar penting, paksakan enkripsinya dan verifikasi lawan bicaranya.

Semoga artikel ini membantu.