Sejarah Lengkap Versi SSL dan TLS: Dari tahun 1994 hingga saat ini

Selama lebih dari tiga dekade, protokol SSL dan TLS telah melindungi miliaran transaksi online. Apa yang dimulai sebagai proyek keamanan ambisius Netscape pada tahun 1994 berkembang menjadi standar enkripsi yang canggih saat ini. Sejarah SSL ini mencakup enam versi protokol utama, peningkatan keamanan yang tak terhitung jumlahnya, dan pergeseran mendasar dalam cara kita berpikir tentang keamanan web.

Memahami versi SSL/TLS bukan hanya tentang mengetahui protokol mana yang sudah tidak digunakan lagi. Ini tentang mengenali bagaimana setiap kerentanan, serangan, dan terobosan membentuk lanskap saat ini di mana TLS 1.3 mengamankan 95% lalu lintas web terenkripsi.

---

Daftar Isi

1. Kelahiran Protokol SSL di Netscape
2. SSL 3.0 – Desain Ulang Protokol Lengkap
3. TLS 1.0 – Era Standardisasi IETF
4. TLS 1.1 dan TLS 1.2 – Peningkatan Keamanan Tambahan
5. TLS 1.3 – Standar Keamanan Modern
6. Kesalahpahaman Umum Tentang Pembuatan Versi SSL/TLS
7. Peran Otoritas Sertifikat dalam Evolusi SSL/TLS
8. Pencapaian Industri yang Membentuk Adopsi HTTPS
9. Kerentanan Keamanan Utama yang Mendorong Evolusi Protokol
10. Masa Depan Protokol SSL/TLS

---

---

Kelahiran Protokol SSL di Netscape

SSL 1.0 – Upaya Pertama yang Belum Dirilis (1994)

Taher Elgamal, kepala ilmuwan Netscape, mendesain Lapisan Soket Aman yang asli di tahun 1994. Tetapi SSL 1.0 tidak pernah melihat cahaya hari. Para peneliti keamanan di Netscape menemukan kelemahan kritis sebelum dirilis ke publik, kerentanan yang cukup serius untuk menghapus seluruh versi.

Pelajarannya jelas: protokol kriptografi membutuhkan peninjauan ekstensif sebelum diterapkan. Kemunduran ini, meskipun membuat frustrasi, membentuk pola pengujian yang ketat yang akan menentukan pengembangan SSL dan TLS di masa depan.

SSL 2.0 – Rilis Publik Pertama (1995)

Kapan SSL keluar? Jawabannya adalah Februari 1995, ketika Netscape membundel SSL 2.0 dengan Navigator 1.1. Versi SSL ini memperkenalkan konsep dasar yang masih digunakan sampai sekarang: konsep Jabat tangan SSL jabat tangan SSL, sertifikat digitalX.509, dan otentikasi server.

Tetapi SSL 2.0 memiliki masalah. SSL 2.0 mengandalkan MD5 untuk autentikasi pesan, menggunakan kunci yang sama untuk enkripsi dan autentikasi, dan tidak memiliki proteksi untuk jabat tangan itu sendiri. Penyerang dapat menurunkan koneksi ke enkripsi 40-bit yang lebih lemah tanpa disadari oleh salah satu pihak.

IETF secara resmi tidak lagi menggunakan SSL 2.0 pada bulan Maret 2011 melalui RFC 6176. Pada saat itu, sebagian besar server sudah beralih.

---

SSL 3.0 – Desain Ulang Protokol Lengkap

Peningkatan Utama atas SSL 2.0 (1996)

Paul Kocher, Phil Karlton, dan Alan Freier menulis ulang protokol SSL secara menyeluruh untuk versi 3.0, yang dirilis pada bulan November 1996. Mereka memisahkan lapisan transport data dari lapisan pesan, menambahkan dukungan untuk pertukaran kunci Diffie-Hellman dan rangkaian sandi Fortezza, dan mengimplementasikan penguncian 128-bit yang tepat.

SSL 3.0 juga memperkenalkan kompresi catatan dan negosiasi rangkaian sandi yang lebih fleksibel. IETF kemudian mendokumentasikannya dalam RFC 6101, yang mengakui kepentingan historisnya. Selama hampir dua dekade, SSL 3.0 berfungsi sebagai opsi mundur untuk sistem lama.

Kerentanan POODLE dan Pengabaian SSL 3.0

Pada bulan Oktober 2014, tim keamanan Google menemukan POODLE (Padding Oracle pada Enkripsi Lama yang Diturunkan). Serangan ini mengeksploitasi cara SSL 3.0 menangani mode padding cipher block chaining (CBC). Penyerang dapat mendekripsi cookie HTTP yang aman dengan memaksa browser untuk menurunkan versi dari TLS ke SSL 3.0.

IETF merespons dengan cepat, dengan tidak lagi menggunakan SSL 3.0 pada bulan Juni 2015 melalui RFC 7568. Ini menandai berakhirnya era SSL. Ketika orang bertanya tentang“versi SSL terbaru“, jawabannya adalah SSL 3.0, karena SSL itu sendiri tidak pernah diperbarui lagi. Obor telah beralih ke Keamanan Lapisan Transport.

---

TLS 1.0 – Era Standardisasi IETF

Dari Transisi SSL ke TLS (1999)

Pada akhir tahun 1990-an, IETF ingin menstandarkan protokol keamanan internet. Tim Dierks dan Christopher Allen memimpin upaya untuk mengubah SSL menjadi standar terbuka. Microsoft dan Netscape menegosiasikan penamaan-TransportLayer Security adalah kompromi yang gagal.

TLS 1.0, yang diterbitkan sebagai RFC 2246 pada bulan Januari 1999, pada dasarnya adalah SSL 3.1 dengan nama baru. Perbedaannya kecil tetapi cukup berarti untuk merusak kompatibilitas. Anda tidak dapat mencampur klien SSL 3.0 dengan server TLS 1.0 tanpa implementasi yang cermat.

Perbedaan Utama dari SSL 3.0

TLS 1.0 meningkatkan kriptografi yang mendasarinya. Ini menggantikan kode otentikasi pesan khusus SSL (MAC) dengan HMAC, yang distandardisasi oleh para kriptografer. Fungsi derivasi kunci berubah untuk mencegah serangan teoretis tertentu. Sistem peringatan diperluas dengan kode kesalahan yang lebih spesifik.

TLS 1.0 juga membutuhkan dukungan untuk rangkaian sandi DSS/DH, memberikan implementasi yang lebih fleksibel. Perubahan ini terlihat kecil, tetapi mencerminkan pergeseran dari pengembangan kepemilikan ke standardisasi yang digerakkan oleh komunitas. IETF sekarang mengendalikan evolusi protokol.

---

TLS 1.1 dan TLS 1.2 – Peningkatan Keamanan Tambahan

TLS 1.1 Perlindungan Terhadap Serangan CBC (2006)

Dirilis pada bulan April 2006 melalui RFC 4346, TLS 1.1 menangani kerentanan CBC tertentu. Perubahan terbesar? Vektor inisialisasi eksplisit (IV) menggantikan IV implisit. Hal ini mencegah penyerang untuk memprediksi IV dan mengeksploitasi rantai blok sandi.

TLS 1.1 juga meningkatkan penanganan kesalahan untuk catatan yang di-padding. Alih-alih mengungkapkan kesalahan padding yang spesifik, ia mengembalikan peringatan umum bad_record_mac. Perubahan ini melindungi dari BEAST (Eksploitasi Peramban Terhadap SSL/TLS), yang ditemukan beberapa tahun kemudian di tahun 2011.

Registrasi parameter IANA dibuat, membuat manajemen rangkaian sandi menjadi lebih terorganisir. Tetapi adopsi berjalan lambat. Banyak organisasi yang melewatkan TLS 1.1 sepenuhnya, menunggu perbaikan TLS 1.2 yang lebih besar.

TLS 1.2 Fleksibilitas yang Ditingkatkan (2008)

Kapan TLS 1.2 dirilis? Agustus 2008, melalui RFC 5246. Pembaruan ini membawa perubahan yang paling signifikan sejak SSL 3.0. Protokol beralih dari kombinasi MD5/SHA-1 yang dikodekan dengan kode keras ke fungsi pseudorandom yang ditentukan oleh rangkaian sandi (PRF). SHA-256 menjadi standar baru.

TLS 1.2 memperkenalkan enkripsi terautentikasi dengan mode sandi data tambahan (AEAD), termasuk AES-GCM dan ChaCha20-Poly1305. Ini memberikan fleksibilitas implementasi dalam memilih algoritma hash dan tanda tangan. Kemampuan beradaptasi ini terbukti sangat penting seiring dengan berkembangnya standar kriptografi.

Protokol ini masih digunakan secara luas hingga saat ini. Sekitar 95,8% situs web masih mendukung TLS 1.2, dan sering kali berjalan bersamaan dengan TLS 1.3. Pada bulan Maret 2021, IETF secara bersama-sama menghentikan penggunaan TLS 1.0 dan 1.1 melalui RFC 8996, menjadikan TLS 1.2 sebagai standar minimum yang dapat diterima.

---

---

TLS 1.3 – Standar Keamanan Modern

Lima Tahun dalam Pengembangan (2018)

TLS 1.3 membutuhkan waktu satu dekade untuk hadir. IETF menerbitkan RFC 8446 pada bulan Agustus 2018 setelah 28 draf dan kolaborasi yang ekstensif. Kesederhanaan dan kinerja mendorong desain ulang. Kelompok kerja menghapus fitur-fitur lama, menyederhanakan jabat tangan, dan menghilangkan seluruh kelas kerentanan.

Google, Mozilla, Microsoft, dan Apple dengan cepat menambahkan dukungan. Pada tahun 2019, semua peramban utama dapat menegosiasikan koneksi TLS 1.3. Cloudflare dan penyedia CDN lainnya mengaktifkannya secara default. Versi TLS terbaru tidak hanya meningkatkan keamanan, tetapi juga membuat koneksi terenkripsi menjadi lebih cepat.

Peningkatan Keamanan Revolusioner

TLS 1.3 menghapus semua yang rusak atau lemah. Rangkaian sandi SHA-1, MD5, RC4, DES, dan 3DES? Hilang. RSA statis dan pertukaran kunci Diffie-Hellman? Dihilangkan. Protokol sekarang membutuhkan kerahasiaan ke depan yang sempurna menggunakan Diffie-Hellman sementara untuk semua koneksi.

Jabat tangan berubah secara mendasar. Setiap pesan setelah ServerHello dienkripsi, menyembunyikan negosiasi dari pengintai. Fungsi derivasi kunci beralih ke Extract-and-Expand (HKDF) berbasis HMAC, memberikan jaminan kriptografi yang lebih baik.

TLS 1.3 juga memperkenalkan mode 0-RTT (zero round-trip time). Klien dapat mengirimkan data terenkripsi pada pesan pertama ke server yang dihubungi sebelumnya, menghilangkan latensi jabat tangan. Mesin state yang disederhanakan membuat implementasi tidak terlalu rentan terhadap kesalahan. ECC pindah ke spesifikasi dasar dengan algoritma tanda tangan baru seperti RSA-PSS.

Adopsi dan Koeksistensi Saat Ini

Apa versi TLS terbaru? TLS 1.3 memegang gelar itu. Tetapi TLS 1.2 tidak akan segera diluncurkan. Organisasi membutuhkan waktu untuk meng-upgrade peladen, menguji kompatibilitas, dan memperbarui perangkat lunak klien. Sebagian besar situs yang sadar akan keamanan sekarang mendukung keduanya, membiarkan klien memilih opsi terbaik yang tersedia.

Koeksistensi bekerja dengan baik. Server menegosiasikan versi tertinggi yang didukung bersama. Klien yang tidak dapat menangani TLS 1.3 akan kembali ke TLS 1.2. Pendekatan migrasi bertahap ini mencegah bencana kompatibilitas yang mengganggu transisi sebelumnya.

---

Kesalahpahaman Umum Tentang Pembuatan Versi SSL/TLS

Mengapa Tidak Ada TLS 2.0

Kapan tanggal rilis TLS 2.0? Tidak ada. TLS 2.0 tidak ada dan tidak akan pernah ada. IETF menggunakan versi bertahap: TLS 1.0, 1.1, 1.2, 1.3. Versi berikutnya, jika datang, adalah TLS 1.4 atau mungkin TLS 2.0, tetapi melompat langsung ke “TLS 2.0” setelah SSL 3.0 akan menyebabkan kebingungan yang sangat besar.

Orang sering mengharapkan protokol menggunakan nomor versi utama (seperti perangkat lunak yang melompat dari versi 1 ke versi 2). Tetapi protokol kriptografi berevolusi secara lebih konservatif, dengan setiap rilis yang dibangun di atas rilis sebelumnya.

Terminologi SSL vs TLS

Mintalah “sertifikat SSL” dan Anda akan mendapatkan sertifikat yang bekerja dengan TLS 1.2 dan TLS 1.3. Industri ini masih menggunakan “SSL” dalam pemasaran karena sudah tidak asing lagi. Meskipun versi SSL saat ini secara teknis sudah tidak ada (SSL berakhir pada versi 3.0), istilah ini masih digunakan.

Otoritas sertifikat seperti DigiCert dan Sectigo menjual “sertifikat SSL” yang secara eksklusif menggunakan protokol TLS. Ini membingungkan tetapi tidak berbahaya. Ingatlah: ketika seseorang menyebutkan SSL pada tahun 2026, hampir pasti yang dimaksud adalah TLS.

---

Peran Otoritas Sertifikat dalam Evolusi SSL/TLS

Pengembangan Jenis Validasi

Sertifikat SSL awal mahal dan lambat. Validasi Bisnis membutuhkan beberapa hari atau minggu verifikasi manual. Pada tahun 2002, GeoTrust memperkenalkan Validasi Domainyang mengotomatiskan proses dengan memverifikasi kepemilikan domain melalui email atau catatan DNS.

SertifikatValidasi yang Diperpanjang hadir pada tahun 2007, menjanjikan jaminan tertinggi dengan bilah alamat hijau pada peramban. Let’s Encrypt diluncurkan pada tahun 2015, menawarkan sertifikat Validasi Domain gratis melalui penerbitan otomatis. Cloudflare mengikuti dengan program sertifikat gratis mereka sendiri. Perubahan-perubahan ini mendemokratisasi HTTPSmembuat enkripsi dapat diakses oleh situs web kecil.

Pengurangan Masa Berlaku Sertifikat

Masa berlaku sertifikat terus menyusut. Persyaratan awal menurunkan masa berlaku maksimum dari lima tahun menjadi tiga tahun pada tahun 2015. Dua tahun menjadi batasnya pada tahun 2018. Safari Apple memberlakukan batas maksimum satu tahun pada tahun 2020, memaksa peramban lain untuk mengikutinya.

Sekarang industri ini mendorong ke arah siklus hidup sertifikat yang lebih pendek lagi. Forum CA/Browser telah menetapkan pengurangan yang jelas dalam masa berlaku sertifikat: 200 hari mulai 15 Maret 2026,100 hari mulai 15 Maret 2027, dan hanya 47 hari pada 15 Maret 2029.

Pergeseran ini membuat manajemen sertifikat manual menjadi tidak praktis, sehingga mendorong organisasi menuju solusi otomatis seperti Certificate-as-a-Service (CaaS) berbasis ACME, di mana validasi, penerbitan, dan pembaruan ditangani secara otomatis.

---

Pencapaian Industri yang Membentuk Adopsi HTTPS

Dorongan HTTPS Google

Pada bulan Agustus 2014, Google mengumumkan HTTPS sebagai sinyal peringkat. Keputusan tunggal ini mengubah sejarah SSL. Para webmaster yang mengabaikan enkripsi tiba-tiba memiliki alasan bisnis untuk peduli. Pada tahun 2016, setengah dari semua lalu lintas web dienkripsi.

Chrome 68 mengambil langkah selanjutnya pada bulan Juli 2018, menandai semua situs HTTP sebagai “Tidak Aman.” Peringatan tersebut muncul di bilah alamat untuk setiap halaman yang tidak terenkripsi. Saat ini, lebih dari 95% lalu lintas web menggunakan HTTPS. Google mengubah enkripsi dari praktik terbaik keamanan menjadi persyaratan bisnis.

Evolusi Indikator Keamanan Browser

Ingat bilah alamat hijau Validasi Diperpanjang? Sudah tidak ada lagi. Chrome menghapusnya pada tahun 2020 setelah penelitian menunjukkan bahwa pengguna tidak memperhatikan atau memahaminya. Ikon gembok itu sendiri menghilang, digantikan oleh indikator netral yang menormalkan HTTPS dan bukannya memberikan penghargaan.

Chrome 69 menghapus teks “Secure”, dan hanya menyisakan gembok. Peramban saat ini berfokus pada peringatan tentang koneksi yang tidak aman daripada memuji koneksi yang aman. Pesannya: HTTPS adalah ekspektasi default, bukan sesuatu yang istimewa.

---

Kerentanan Keamanan Utama yang Mendorong Evolusi Protokol

Serangan Penting pada SSL/TLS

POODLE menyerang SSL 3.0 pada tahun 2014, mengeksploitasi kerentanan padding oracle dalam mode CBC. Para penyerang dapat mendekripsi cookie yang aman dengan menurunkan koneksi dan berulang kali memodifikasi ciphertext. Serangan itu membunuh SSL 3.0 dalam beberapa bulan.

BEAST menargetkan TLS 1.0 di tahun 2011, menggunakan kelemahan CBC yang serupa. Penyerang dapat mendekripsi cookie HTTPS dengan menyuntikkan kode sisi klien dan mengamati respons yang dienkripsi. Perbaikannya membutuhkan penerapan IV eksplisit di TLS 1.1.

BREACH menyalahgunakan kompresi HTTP pada tahun 2013. Serangan ini tidak menargetkan protokol TLS itu sendiri, tetapi menunjukkan bagaimana keputusan lapisan aplikasi memengaruhi keamanan. Heartbleed, yang ditemukan pada tahun 2014, mengekspos celah kritis OpenSSL yang membocorkan kunci pribadi dan data pengguna.

Pelajaran yang Dipetik

Setiap kerentanan membuktikan hal yang sama: kompatibilitas ke belakang itu berbahaya. Menjaga protokol lama tetap hidup untuk sistem lama menciptakan vektor serangan. Industri ini belajar untuk tidak menggunakan lagi secara agresif dan memaksakan peningkatan.

Para peneliti keamanan juga layak mendapatkan pujian. Pengungkapan kerentanan kepada publik mempercepat perbaikan. Tanpa POODLE, SSL 3.0 mungkin masih mengintai di konfigurasi server saat ini.

---

Masa Depan Protokol SSL/TLS

Kriptografi Pasca-Kuantum

Komputer kuantum mengancam algoritma enkripsi saat ini. RSA dan kriptografi kurva elips dapat menjadi usang setelah mesin kuantum mencapai skala yang memadai. NIST sedang menstandarkan algoritma pasca-kuantum yang dirancang untuk melawan serangan kuantum.

TLS akan membutuhkan pembaruan untuk mendukung algoritma yang tahan terhadap kuantum ini. Transisi ini tidak akan mudah, kriptografi pasca-kuantum menggunakan kunci yang lebih besar dan pendekatan matematika yang berbeda. Tetapi evolusi protokol yang membawa kita dari SSL 2.0 ke TLS 1.3 membuktikan bahwa komunitas dapat menangani transisi besar.

Teknologi yang Sedang Berkembang

DTLS (Datagram Transport Layer Security) memperluas TLS ke koneksi UDP. QUICyang dikembangkan oleh Google dan distandarisasi oleh IETF, mengintegrasikan enkripsi secara langsung ke dalam lapisan transport. Protokol-protokol ini dibangun di atas fondasi kriptografi TLS sambil beradaptasi dengan kasus penggunaan yang berbeda.

Alternatif berbasis blockchain seperti Remme bereksperimen dengan PKI terdistribusi. Otoritas sertifikat terus berkembang, mengotomatiskan lebih banyak proses dan mendukung masa berlaku yang lebih pendek. Apa yang akan terjadi setelah TLS 1.3? Mungkin perbaikan bertahap daripada desain ulang yang lengkap. TLS 1.3 melakukan banyak hal dengan benar.

---

Tetap Terkini dengan Sertifikat TLS 1.3-Ready SSL Dragon

Memahami evolusi protokol adalah satu hal. Menerapkan standar enkripsi modern adalah hal lain. SSL Dragon menyediakan sertifikat digital yang sepenuhnya kompatibel dengan TLS 1.3 dan TLS 1.2, mendukung protokol kriptografi dan rangkaian sandi terbaru.

Kami menawarkan penerbitan yang cepat, enkripsi yang kuat, dan 99,99% kepercayaan peramban melalui kemitraan dengan otoritas sertifikat terkemuka termasuk DigiCert, Sectigo, dan GeoTrust. Solusi manajemen sertifikat otomatis kami membantu Anda menangani siklus hidup 47 hari yang akan datang tanpa kerepotan pembaruan manual.

Bermigrasi dari protokol yang sudah tidak digunakan? Tim dukungan kami yang berdedikasi akan memandu Anda melalui masa transisi. Setiap pembelian mencakup jaminan uang kembali 25 hari. Jelajahi portofolio sertifikat kami hari ini dan amankan infrastruktur Anda dengan versi TLS terbaru.