Dunia bergerak ke TLS 1.3, yang merupakan hal yang sangat bagus! Artikel ini menawarkan ikhtisar tingkat tinggi TLS 1.3, dan diskusi tentang efektivitas fitur-fitur barunya.
Transport Layer Security
Transport Layer Security, atau TLS, adalah protokol kriptografi yang melindungi pertukaran data melalui jaringan komputer. TLS telah menjadi terkenal sebagai S in HTTPS. Lebih spesifik, TLS digunakan untuk melindungi data pengguna web dari serangan jaringan.
TLS dirancang sebagai alternatif yang lebih aman dari pendahulunya Secure Sockets Layer (SSL). Selama bertahun-tahun, peneliti keamanan telah menemukan tumpukan kerentanan yang memengaruhi SSL, yang memotivasi IETF untuk merancang TLS dalam upaya untuk menguranginya.
Ironisnya, versi sebelumnya dari TLS juga dipengaruhi oleh kerentanan berbahaya, yang pada akhirnya menyebabkannya TLS 1.2 (yaitu versi default yang direkomendasikan oleh profesional industri).
Mayoritas kerentanan protokol yang diketahui telah diatasi TLS 1.2, tetapi tingkat keamanan ini masih merupakan hasil dari serangkaian tambalan di atas desain yang cacat.
Sebagai tanggapan, TLS 1.3 disusun dari awal dalam upaya mendesain rapi yang modern dan aman TLS protokol. Lima tahun pengujian kemudian, akhirnya disetujui dan sekarang hampir menjadi standar keamanan Internet default.
TLS versi dan dokumen RFC masing-masing dapat ditemukan dalam daftar di bawah ini:
- TLS 1.0 diterbitkan sebagai RFC 2246 di 1996
- TLS 1.1 diterbitkan sebagai RFC 4346 di 2006
- TLS 1.2 diterbitkan sebagai RFC 5246 di 2008
- TLS 1.3 diterbitkan sebagai standar yang diusulkan dalam RFC 8446 di 2018.
Bagaimana lebih tua TLS versi bekerja?
Untuk membahas secara efektif manfaat TLS 1.3, pertama-tama kita harus berbicara tentang usia TLS versi berfungsi (dan bagaimana tidak).
TLS adalah hibrida cryptosystem, artinya ia menggunakan keduanya asimetris (kunci publik) dan simetris (berbasis kata sandi / frase). Ini berhubungan dengan kriptografi asimetris menjadi lipat lebih lambat dari ekuivalen simetrisnya.
Akibatnya, TLS hanya menggunakan kunci publik sehingga klien dan server dapat bertukar kunci simetris dengan aman. Kunci ini kemudian dapat digunakan untuk mengenkripsi semua komunikasi berikutnya, menghindari overhead kinerja yang dikenakan oleh enkripsi asimetris.
TLS 1.2 mendukung beberapa algoritma pertukaran kunci (misalnya RSA, DH, dll.), Bersama dengan beberapa algoritma (juga dikenal sebagai cipher) digunakan untuk mengenkripsi dan mendekripsi pesan. Opsi alternatif dalam jumlah besar ini membutuhkan klien dan server untuk bernegosiasi, sehingga semua pihak menggunakan hal yang sama TLS parameter.
Negosiasi ini distandarisasi dalam sebuah protokol yang disebut jabatan. Jika Anda tidak terbiasa dengan itu, silakan merujuk artikel ini for more information.
Jadi ada apa dengan TLS 1.2?
Meskipun TLS 1.2 telah terbukti berfungsi dengan baik dalam banyak kasus, ada kekhawatiran tentang keseluruhan tingkat keamanan dan privasi yang diberikannya setelah bertahun-tahun melakukan patching dan revisi.
Terlepas dari pertimbangan keamanan, TLS 1.2 juga memberlakukan kinerja yang tidak perlu dan overhead jaringan.
TLS 1.2 masalah keamanan
Selama bertahun-tahun, para peneliti (dan penyerang) telah menemukan banyak kerentanan TLS 1.2 komponen, termasuk algoritma pertukaran kunci, sandi, dan tanda tangan digital. Beberapa di antaranya adalah bug implementasi yang mungkin pernah Anda dengar, seperti Heartbleed or BERSERK. Namun, beberapa di antaranya merupakan kerentanan protokol - yaitu, mereka mengeksploitasi keputusan desain yang buruk sebelumnya TLS versi (mis. sebelumnya TLS 1.2).
Meskipun sebagian besar implementasi dan bug lainnya telah diperbaiki TLS 1.2, sayangnya kerentanan dalam desain protokol tidak dapat diperbaiki hanya dengan menggunakan tambalan perangkat lunak. Ternyata, untuk melakukan itu IETF harus mendesain ulang sepenuhnya protokol jabat tangan di TLS 1.3.
Ada banyak kekhawatiran tentang TLS keamanan, tapi salah satu yang paling berdampak adalah kesadaran itu TLS 1.2 (dan semua versi sebelumnya, termasuk SSL) rentan terhadap serangan downgrade karena cacat dalam desain protokol jabat tangan. Lebih spesifik, TLS 1.2 tidak menggunakan tanda tangan digital untuk melindungi integritas jabat tangan. Tanda tangan melindungi sebagian dari jabat tangan, hanya setelah negosiasi sandi-suite.
Sebagai akibatnya, penyerang dapat memanipulasi negosiasi cipher-suite pihak ketiga yang terjadi dalam jaringan komputer yang sama (misalnya wifi bandara), dan memaksakan penggunaan sandi yang tidak aman. Mereka kemudian dapat memecahkan sandi yang rentan itu dan mendapatkan akses tidak beralasan ke seluruh percakapan.
TLS 1.2 masalah kinerja
Selain pertimbangan keamanan ini, TLS 1.2 kebutuhan untuk bernegosiasi TLS parameter dapat memberlakukan overhead kinerja pada HTTPS (atau lainnya TLS dilindungi) komunikasi.
TLS Jabat tangan 1.2 langkah 4 membutuhkan dua pertukaran bolak-balik, pertama untuk memilih cipher-suite, dan kemudian untuk menukar sertifikat dan kunci simetris (atau key share).
Ini berarti untuk setiap TLS koneksi yang akan dibangun, dua transaksi tambahan dengan server diperlukan. Hasil dari, TLS koneksi membutuhkan lebih banyak bandwidth dan daya daripada HTTP (tidak terenkripsi), yang bisa sangat mahal untuk aplikasi Internet-of-Things (IoT), di mana konsumsi daya dan bandwidth yang rendah menjadi kendala yang sulit.
TLS 1.2 masalah privasi
Terakhir, TLS 1.2 telah dikritik karena membahayakan privasi pengguna web.
Lebih spesifik, TLS menawarkan ekstensi yang dikenal sebagai Indikasi Nama Server atau SNI. SNI memungkinkan nama host server untuk dimasukkan dalam jabat tangan SSL awal. Ekstensi ini digunakan untuk hosting virtual, di mana server dapat melayani beberapa domain pada alamat IP dan port yang sama, sambil menampilkan sertifikat berbeda untuk setiap domain.
In TLS 1.2, SNI dikirim tidak terenkripsi, jadi meskipun menggunakan HTTPS, penyerang jaringan dapat membocorkan informasi ini dan melacak halaman web yang dikunjungi pengguna.
Bagaimana TLS 1.3 memperbaiki semua itu?
TLS 1.2 (dan versi sebelumnya) difokuskan pada pemeliharaan kompatibilitas ke belakang. Setiap versi dibangun di atas versi sebelumnya dengan revisi kecil yang mencoba menghilangkan kerentanan yang dipublikasikan di antaranya TLS versi.
Sayangnya, ini juga berarti bahwa keputusan desain protokol yang buruk (misalnya jabat tangan yang tidak terlindungi) juga diwariskan dalam versi yang lebih baru.
TLS 1.3 mengabaikan kompatibilitas mundur demi desain keamanan yang tepat. Ini telah dirancang dari awal untuk menyediakan fungsionalitas yang mirip (namun tidak kompatibel) TLS 1.2, tetapi dengan peningkatan kinerja, privasi, dan keamanan yang signifikan.
TLS Keamanan 1.3
Prinsip inti TLS 1.3 adalah kesederhanaan. Di versi baru, semua algoritme pertukaran kunci, kecuali Diffie-Hellman (DH) pertukaran kunci, telah dihapus. TLS 1.3 juga telah mendefinisikan satu set parameter DH yang telah dicoba dan diuji, menghilangkan kebutuhan untuk menegosiasikan parameter dengan server.
Apalagi, TLS 1.3 tidak lagi mendukung sandi yang tidak perlu atau rentan, seperti mode CBC dan sandi RC4. Cipher ini dikenal rentan terhadap serangan, tetapi masih didukung di sebagian besar TLS implementasi untuk kompatibilitas lama. Untungnya, serbuan serangan downgrade baru-baru ini mempengaruhi awal TLS versi memotivasi IETF untuk sepenuhnya menghapus sandi tersebut dari TLS 1.3.
Selain itu, TLS 1.3 mengharuskan server untuk menandatangani seluruh jabat tangan secara kriptografis, termasuk negosiasi sandi, yang mencegah penyerang memodifikasi parameter jabat tangan apa pun. Artinya itu TLS 1.3 secara arsitektur tahan terhadap serangan downgrade yang mempengaruhi sebelumnya TLS versi.
Akhirnya, tanda tangan itu sendiri juga ditingkatkan dengan menerapkan standar baru, yang disebut RSA-PSS. Tanda tangan RSA-PSS kebal terhadap serangan kriptografi yang mempengaruhi skema tanda tangan yang digunakan sebelumnya TLS versi.
TLS TANPA kinerja
Selain peningkatan keamanan, pengurangan set parameter dan jabat tangan yang disederhanakan TLS 1.3 juga berkontribusi untuk meningkatkan kinerja secara keseluruhan. Karena hanya ada satu algoritme pertukaran kunci (dengan parameter bawaan) dan hanya segelintir cipher yang didukung, bandwidth mutlak diperlukan untuk menyiapkan TLS 1.3 saluran jauh lebih sedikit dari versi sebelumnya.
Selain itu, TLS 1.3 sekarang mendukung protokol jabat tangan baru, yang disebut Mode 1-RTT. Dalam 1-RTT, klien dapat mengirim share kunci DH dalam pesan jabat tangan pertama, karena itu dapat memastikan parameter yang akan digunakan oleh server. Dalam kasus yang jarang terjadi bahwa server tidak mendukung mereka, itu dapat menghasilkan kesalahan sehingga klien akan mengirim konfigurasi yang berbeda.
Daripada menegosiasikan parameter terlebih dahulu dan kemudian menukar kunci atau pembagian kunci, TLS 1.3 memungkinkan klien untuk mengatur a TLS saluran dengan hanya satu transaksi bolak-balik (bukan dua, seperti yang telah dilakukan sebelumnya). Ini dapat memiliki efek kumulatif yang besar dalam pemrosesan, daya, dan sumber daya jaringan yang diperlukan klien untuk berkomunikasi dengan server melalui TLS 1.3.
Pengoptimalan kinerja tidak berhenti di sini, dengan yang lain TLS 1.3 fitur, yang disebut Mode Lanjutkan 0-RTT. Saat browser mengunjungi server untuk pertama kalinya dan berhasil menyelesaikan a TLS jabat tangan, klien dan server dapat menyimpan kunci enkripsi yang dibagikan sebelumnya secara lokal.
Jika browser mengunjungi server lagi, ia dapat menggunakan kunci resume ini untuk mengirim data aplikasi terenkripsi dalam pesan pertamanya ke server. Ini memiliki latensi yang sama dengan HTTP yang tidak terenkripsi, karena jabat tangan awal tidak diperlukan.
Perlu dicatat bahwa telah ada keamanan kekhawatiran tentang mode 0-RTT di masa lalu.
TLS 1.3 privasi
Belajar dari kesalahan masa lalu, TLS 1.3 sekarang menawarkan file perpanjangan yang mengenkripsi informasi SNI. Jika digunakan dengan benar, ekstensi ini mencegah penyerang membocorkan nama domain server jarak jauh, sehingga mereka tidak memiliki metode untuk melacak riwayat pengguna HTTPS. Fitur ini memberikan privasi yang lebih besar kepada pengguna Internet daripada versi sebelumnya TLS.
Kesimpulan
Sementara TLS 1.2 telah melayani dengan hormat selama ini, TLS 1.3 terbukti lebih aman dan efisien. TLS 1.3 telah diuji secara ekstensif dalam implementasi browser eksperimental, dan sekarang siap untuk diganti TLS 1.2 sebagai protokol keamanan jaringan pilihan. Penerbitan TLS 1.3 adalah langkah besar menuju Internet yang lebih cepat dan lebih aman untuk semua.
Terima kasih telah memilih SSL.com, di mana kami percaya a lebih aman Internet adalah lebih baik Internet.
