Perbedaan antara SSL & TLS

91

Menurut wikipedia: http://en.wikipedia.org/wiki/Transport_Layer_Security

Sepertinya TLS adalah pengganti SSL, tetapi sebagian besar situs web masih menggunakan SSL?

Howard
sumber
4
"sebagian besar situs web masih menggunakan SSL". Berikut survei yang baik tentang dukungan protokol trustworthyinternet.org/ssl-pulse/#chart-protocol-support
Kolonel Panic
Pertanyaan serupa yang lebih populer: security.stackexchange.com/questions/5126/…
Vadzim

Jawaban:

60

Singkatnya, TLSv1.0 kurang lebih adalah SSLv3.1. Anda dapat menemukan detail lebih lanjut dalam pertanyaan ini di ServerFault .

Sebagian besar situs web sebenarnya mendukung SSLv3 dan TLSv1.0 setidaknya, seperti yang ditunjukkan oleh penelitian ini (makalah Lee, Malkin, dan Nahum: Kekuatan Kriptografi Server SSL / TLS: Praktik Saat Ini dan Terbaru , IMC 2007) (tautan diperoleh dari daftar TLS IETF ). Lebih dari 98% mendukung TLSv1 +.

Saya pikir alasan mengapa SSLv3 masih digunakan adalah untuk dukungan lama (meskipun sebagian besar browser mendukung TLSv1 dan beberapa TLSv1.1 atau bahkan TLSv1.2 saat ini). Hingga beberapa waktu yang lalu, beberapa distribusi masih memiliki SSLv2 (dianggap tidak aman) secara default bersama dengan yang lain.

(Anda mungkin juga menganggap pertanyaan ini menarik, meskipun ini tentang pola penggunaan TLS daripada SSL vs. TLS (Anda sebenarnya bisa memiliki pola yang sama dengan SSL). Ini tidak berlaku untuk HTTPS, karena HTTPS menggunakan SSL / TLS dari awal koneksi.)

Bruno
sumber
23

Dari http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

Pada awal 90-an, pada awal World Wide Web, beberapa insinyur di Netscape mengembangkan protokol untuk membuat permintaan HTTP yang aman, dan yang mereka temukan disebut SSL. Mengingat pengetahuan yang relatif langka tentang protokol aman pada saat itu, serta tekanan kuat yang dialami semua orang di Netscape, upaya mereka hanya dapat dilihat sebagai tindakan yang sangat heroik. Sungguh menakjubkan bahwa SSL telah bertahan selama itu, berbeda dengan sejumlah protokol lain dari model yang sama. Kami pasti telah belajar banyak sejak saat itu, tetapi hal tentang protokol dan API adalah sangat sedikit kemunduran.

Ada dua pembaruan utama pada protokol SSL, SSL 2 (1995) dan SSL 3 (1996). Ini dilakukan dengan hati-hati agar kompatibel ke belakang, untuk memudahkan adopsi. Namun kompatibilitas mundur merupakan kendala untuk protokol keamanan yang dapat berarti rentan ke belakang.

Jadi diputuskan untuk memecah kompatibilitas mundur, dan protokol baru bernama TLS 1.0 (1999). (Kalau dipikir-pikir, mungkin lebih jelas untuk menamakannya TLS 4)

Perbedaan antara protokol ini dan SSL 3.0 tidak dramatis, tetapi cukup signifikan sehingga TLS 1.0 dan SSL 3.0 tidak saling beroperasi.

TLS telah direvisi dua kali, TLS 1.1 (2006) dan TLS 1.2 (2008).

Pada 2015, semua versi SSL rusak dan tidak aman (serangan POODLE) dan browser menghapus dukungan. TLS 1.0 ada di mana-mana, tetapi hanya 60% situs yang mendukung TLS 1.1 dan 1.2 , keadaan yang menyedihkan.


Jika Anda tertarik dengan hal ini, saya merekomendasikan ceramah Moxie Marlinspike yang pintar dan lucu di https://www.youtube.com/watch?v=Z7Wl2FW2TcA

Kolonel Panik
sumber
Saya ingat posting Usenet news: comp.sources.unix yang berjudul Secure Sockets Layer pada akhir 1980-an. Saya ragu itu memiliki banyak hubungan dengan apa yang dilakukan Netscape selain namanya.
Marquis dari Lorne
11

tls1.0 berarti sslv3.1

tls1.1 berarti sslv3.2

tls1.2 berarti sslv3.3

rfc baru saja mengubah nama, Anda dapat menemukan kode hex tls1.0 adalah 0x0301, yang berarti sslv3.1

zhenyu li
sumber
2

TLS mempertahankan kompatibilitas mundur dengan SSL dan oleh karena itu protokol komunikasi hampir identik di salah satu versi yang disebutkan di sini. Dua perbedaan penting antara SSL v.3, TLS 1.0, dan TLS 1.2, adalah fungsi pseudo-random (PRF) dan fungsi hashing HMAC (SHA, MD5, handshake), yang digunakan untuk membuat blok kunci simetris untuk Enkripsi Data Aplikasi (kunci server + kunci klien + IV). Perbedaan utama antara TLS 1.1 dan TLS 1.2 adalah bahwa 1.2 memerlukan penggunaan IV "eksplisit" untuk melindungi dari serangan CBC, meskipun tidak ada perubahan pada PRF atau protokol yang diperlukan untuk ini. TLS 1.2 PRF adalah cipher-suite-specific, yang berarti PRF dapat dinegosiasikan selama jabat tangan. SSL pada awalnya dikembangkan oleh Netscape Communications (historis) dan kemudian dikelola oleh Internet Engineering Task Force (IETF, saat ini). TLS dikelola oleh Kelompok Kerja Jaringan. Berikut adalah perbedaan antara fungsi PRF HMAC di TLS:

TLS 1.0 dan 1.1

PRF (rahasia, label, benih) = P_MD5 (S1, label + benih) XOR P_SHA-1 (S2, label + benih);

TLS 1.2

PRF (rahasia, label, benih) = P_hash (rahasia, label + benih)

SensorVista
sumber
0

"Jika tidak rusak, jangan sentuh". SSL3 berfungsi dengan baik di sebagian besar skenario (ada kelemahan mendasar yang ditemukan dalam protokol SSL / TLS pada bulan Oktober, tetapi ini lebih merupakan kesalahan aplikasi daripada prokol itu sendiri), jadi pengembang tidak terburu-buru untuk meningkatkan modul SSL mereka. TLS menghadirkan sejumlah ekstensi dan algoritme keamanan yang berguna, tetapi mereka merupakan tambahan yang berguna dan bukan suatu keharusan. Jadi TLS di sebagian besar server tetap menjadi pilihan. Jika server dan klien mendukungnya, itu akan digunakan.

Pembaruan: di '2016 SSL 3, dan bahkan TLS hingga 1.2 ditemukan rentan terhadap berbagai serangan dan migrasi ke TLS 1.2 direkomendasikan. Ada juga serangan pada implementasi TLS 1.2, meskipun bergantung pada server. TLS 1.3 saat ini sedang dalam pengembangan. Dan sekarang TLS 1.2 adalah suatu keharusan.

Panggilan balik Eugene Mayevski
sumber
2
Tidak, ini adalah kesalahan protokol, dan pengembang harus meningkatkan tumpukan SSL mereka. Dengan demikian, ada pedoman untuk menggunakan ekstensi negosiasi ulang di RFC 5746 untuk SSLv3, selain untuk TLS.
Bruno
Jika Anda membunuh seseorang dengan pisau, ini bukanlah cacat pisau, tapi salah satu otak Anda. Sama disini. Jika protokol digunakan dengan cara yang tidak dirancang untuk itu, itu bukan kesalahan protokol.
Panggilan balik Eugene Mayevski '
1
Protokol dirancang sedemikian rupa sehingga aplikasi di atasnya harus memperlakukannya sebagai soket normal sebanyak mungkin. Masalah negosiasi ulang, tanpa ekstensi baru, memaksa kesadaran oleh lapisan aplikasi (misalnya HTTP). Ada utas yang tertarik tentang topik ini di milis IETF TLS: ietf.org/mail-archive/web/tls/current/msg04000.html
Bruno
1
Saya setuju beberapa di antaranya harus dilakukan di tingkat aplikasi, tetapi saya tidak mengetahui adanya implementasi dan protokol yang memperhitungkannya. Tumpukan tersebut biasanya dapat mengatasi negosiasi ulang yang mereka mulai secara sah, tetapi tidak terlalu banyak jika MITM memulainya (yang merupakan masalah). Itulah mengapa grup IETF TLS memilih untuk memperbaikinya di tingkat TLS, dan itu juga mengapa orang benar-benar harus mengaktifkan ekstensi itu, atau menonaktifkan negosiasi ulang sama sekali.
Bruno
1
Ada masalah yang lebih mendasar di SSL 3.0 daripada yang Anda sebutkan. Misalnya padding oracle CBC, serta penggunaan kembali IV atau record sebelumnya. Yang pertama masih mengganggu TLS tetapi dapat diatasi, sedangkan yang terakhir diperbaiki pada TLS 1.1.
Nikos
0

https://hpbn.co/transport-layer-security-tls/ adalah pengantar yang bagus

Protokol SSL awalnya dikembangkan di Netscape untuk mengaktifkan keamanan transaksi e-niaga di Web, yang membutuhkan enkripsi untuk melindungi data pribadi pelanggan, serta jaminan otentikasi dan integritas untuk memastikan transaksi yang aman. Untuk mencapai hal ini, protokol SSL diimplementasikan pada lapisan aplikasi, langsung di atas TCP (Gambar 4-1), memungkinkan protokol di atasnya (HTTP, email, pesan instan, dan banyak lainnya) untuk beroperasi tidak berubah sambil memberikan keamanan komunikasi saat berkomunikasi di seluruh jaringan.

Jika SSL digunakan dengan benar, pengamat pihak ketiga hanya dapat menyimpulkan titik akhir koneksi, jenis enkripsi, serta frekuensi dan perkiraan jumlah data yang dikirim, tetapi tidak dapat membaca atau memodifikasi data aktual apa pun.

SSL 2.0 adalah versi protokol yang dirilis secara publik pertama, tetapi dengan cepat digantikan oleh SSL 3.0 karena sejumlah kelemahan keamanan yang ditemukan. Karena protokol SSL adalah milik Netscape, IETF membentuk upaya untuk menstandarkan protokol, menghasilkan RFC 2246, yang diterbitkan pada Januari 1999 dan dikenal sebagai TLS 1.0. Sejak itu, IETF terus melakukan iterasi pada protokol untuk mengatasi kelemahan keamanan, serta untuk memperluas kemampuannya: TLS 1.1 (RFC 2246) diterbitkan pada bulan April 2006, TLS 1.2 (RFC 5246) pada bulan Agustus 2008, dan berfungsi sekarang sedang dilakukan untuk mendefinisikan TLS 1.3.

Kolonel Panik
sumber