Jawaban singkat:
SSL adalah pendahulu untuk TLS. SSL adalah protokol eksklusif yang dikembangkan oleh Netscape Communications, yang kemudian distandarisasi dalam IETF dan diganti namanya menjadi TLS. Singkatnya, versi berjalan dalam urutan ini: SSLv2, SSLv3, TLSv1.0, TLSv1.1 dan TLSv1.2.
Berlawanan dengan kepercayaan yang relatif luas, ini sama sekali bukan tentang harus menjalankan layanan pada port yang berbeda dengan SSL dan mampu pada port yang sama dengan varian teks biasa dengan TLS. SSL dan TLS dapat digunakan untuk dua pendekatan. Ini tentang perbedaan antara SSL / TLS pada saat koneksi (kadang-kadang disebut sebagai "SSL / TLS implisit") dan SSL / TLS setelah perintah dikeluarkan pada tingkat protokol, biasanya STARTTLS(kadang-kadang disebut sebagai "SSL / TLS eksplisit") . Kata kuncinya STARTTLSadalah "MULAI", bukan TLS. Ini adalah pesan, pada tingkat protokol aplikasi, untuk menunjukkan perlu ada peralihan ke SSL / TLS, jika belum dimulai sebelum pertukaran protokol aplikasi.
Menggunakan salah satu mode harus sama, asalkan klien dikonfigurasi untuk mengharapkan SSL / TLS dengan satu atau lain cara, agar tidak diturunkan ke koneksi teks biasa.
Jawaban yang lebih panjang:
SSL vs TLS
Sejauh yang saya ketahui, SSLv1 tidak pernah meninggalkan laboratorium. SSLv2 dan SSLv3 adalah protokol yang dikembangkan oleh Netscape. SSLv2 telah dianggap tidak aman untuk sementara waktu, karena rawan serangan downgrade. SSLv3 digunakan secara internal (3,0)sebagai nomor versinya (di dalam ClientHellopesan).
TLS adalah hasil dari standarisasi sebagai protokol yang lebih terbuka di dalam IETF. (Saya pikir saya telah membaca di suatu tempat, mungkin dalam buku E. Rescorla, bahwa nama itu telah dipilih sedemikian rupa sehingga semua peserta sama-sama tidak bahagia dengan itu, sehingga tidak mendukung perusahaan tertentu: ini adalah praktik standar yang cukup umum badan.) Mereka yang tertarik dengan bagaimana transisi dibuat dapat membaca FAQ Daftar SSL-Talk ; ada beberapa salinan dokumen ini, tetapi sebagian besar tautan (ke ) sudah usang.netscape.com
TLS menggunakan pesan yang sangat mirip (cukup berbeda untuk membuat protokol tidak kompatibel, meskipun dimungkinkan untuk menegosiasikan versi umum ). The TLS 1.0 , 1.1 dan 1.2 ClientHello pesan menggunakan (3,1), (3,2), (3,3)untuk menunjukkan nomor versi, yang dengan jelas menunjukkan kelanjutan dari SSL.
Ada lebih banyak detail tentang perbedaan protokol dalam jawaban ini .
Kapan saya menggunakan yang mana? Kapan saya tidak menggunakan yang mana?
Gunakan versi tertinggi yang Anda bisa jika memungkinkan. Dalam praktiknya, sebagai penyedia layanan, ini akan mengharuskan pengguna Anda untuk memiliki klien yang mendukung versi ini. Seperti biasa, selalu merupakan latihan penilaian risiko (sebaiknya didukung dengan kasus bisnis jika sesuai). Ini dikatakan, potong SSLv2 saja.
Selain itu, perhatikan bahwa keamanan yang disediakan oleh SSL / TLS tidak hanya tentang versi yang Anda gunakan, tetapi juga tentang konfigurasi yang tepat: tentu saja lebih baik menggunakan SSLv3 dengan rangkaian sandi yang kuat daripada TLSv1.0 dengan yang dengan lemah (atau suite cipher anonim / null-enkripsi). Beberapa suite sandi, yang dianggap terlalu lemah, telah secara eksplisit dilarang oleh versi TLS yang lebih baru. Tabel di penyedia Java 7 SunJSSE (dan catatan kaki mereka) dapat menarik jika Anda menginginkan detail lebih lanjut.
Akan lebih baik menggunakan setidaknya TLS 1.1, tetapi sayangnya tidak semua klien mendukungnya (mis. Java 6). Saat menggunakan versi di bawah 1.1, tentu layak untuk mengurangi kerentanan BEAST .
Saya umumnya merekomendasikan buku Eric Rescorla - SSL dan TLS: Merancang dan Membangun Sistem yang Aman, Addison-Wesley, 2001 ISBN 0-201-61598-3 kepada orang-orang yang benar-benar menginginkan detail lebih banyak.
SSL / TLS Tersirat vs Eksplisit
Ada mitos yang mengatakan bahwa TLS memungkinkan Anda untuk menggunakan port yang sama sedangkan SSL tidak bisa. Itu tidak benar (dan saya akan meninggalkan penyatuan pelabuhan untuk diskusi ini). Sayangnya, mitos ini tampaknya telah disebarkan kepada pengguna oleh fakta bahwa beberapa aplikasi seperti MS Outlook terkadang menawarkan pilihan antara SSL dan TLS dalam opsi konfigurasi mereka ketika mereka sebenarnya berarti pilihan antara SSL / TLS implisit dan eksplisit. (Ada pakar SSL / TLS di Microsoft, tetapi tampaknya mereka tidak terlibat dalam UI Outlook.)
Saya pikir alasan mengapa kebingungan ini terjadi adalah karena STARTTLSmode. Beberapa orang tampaknya telah memahami ini sebagai STARTTLS= TLS, tetapi ini bukan masalahnya. Kata kuncinya STARTTLSadalah "MULAI", bukan TLS. Mengapa ini tidak dipanggil STARTSSLatau STARTSSLORTLSkarena ekstensi ini ditentukan dalam IETF, yang hanya menggunakan nama yang digunakan dalam spesifikasinya (dengan asumsi bahwa nama TLS pada akhirnya akan menjadi satu-satunya yang bertahan, saya kira).
- SSL pada port yang sama dengan layanan teks biasa: HTTPS proxy.
Saat ini, sebagian besar server HTTPS dapat menangani TLS, tetapi beberapa tahun yang lalu, kebanyakan orang menggunakan SSLv3 untuk HTTPS. HTTPS (secara tegas, distandarisasi sebagai HTTP over TLS ) biasanya membangun koneksi SSL / TLS pada koneksi TCP, dan kemudian bertukar pesan HTTP melalui lapisan SSL / TLS. Ada pengecualian untuk ini ketika menggunakan proxy HTTP di antaranya. Dalam hal ini, klien terhubung ke proksi HTTP secara jelas (biasanya pada port 3128), kemudian mengeluarkan CONNECTperintah HTTP dan, asalkan responsnya berhasil, memulai jabat tangan SSL / TLS dengan mengirimkanClientHellopesan. Semua ini terjadi pada port yang sama sejauh menyangkut hubungan antara browser dan proxy (jelas bukan antara proxy dan server target: itu bahkan bukan mesin yang sama). Ini berfungsi dengan baik dengan SSLv3. Banyak dari kita dalam situasi di belakang proxy akan menggunakan ini terhadap server yang tidak mendukung setidaknya TLS 1.0.
- SSL pada port yang sama dengan layanan teks biasa: e-mail.
Yang ini jelas di luar spesifikasi, tetapi dalam praktiknya, sering berhasil. Secara spesifik, spesifikasi berbicara tentang beralih ke TLS (bukan SSL) setelah menggunakan perintah STARTTLS. Dalam praktiknya, SSL sering bekerja juga (seperti spesifikasi "HTTP over TLS" juga mencakup penggunaan SSL, bukan TLS juga). Anda bisa mencobanya sendiri. Dengan asumsi Anda memiliki server SMTP atau IMAP yang mendukung STARTTLS, gunakan Thunderbird, masuk ke preferensi, opsi lanjutan, editor konfigurasi dan matikan security.enable_tls. Banyak server masih akan menerima koneksi, hanya karena implementasinya mendelegasikan lapisan SSL / TLS ke perpustakaan SSL / TLS yang umumnya akan dapat menangani SSL dan TLS dengan cara yang sama, kecuali jika dikonfigurasi untuk tidak melakukannya. Seperti yang dikatakan oleh FAQ OpenLDAP , "Sementara mekanisme dirancang untuk digunakan dengan TLSv1, sebagian besar implementasi akan mundur ke SSLv3 (dan SSLv2) jika perlu. ". Jika Anda tidak yakin, tanyakan alat seperti Wireshark.
- TLS pada port yang berbeda.
Banyak klien dapat menggunakan TLS 1.0 (setidaknya) untuk protokol di mana varian yang aman berada di port yang berbeda. Jelas, ada sejumlah browser dan server web yang mendukung TLS 1.0 (atau lebih tinggi) untuk HTTPS. Demikian pula, SMTPS, IMAPS, POPS dan LDAPS dapat menggunakan TLS juga. Mereka tidak terbatas pada SSL.
Kapan saya menggunakan yang mana? Kapan saya tidak menggunakan yang mana?
Antara SSL / TLS eksplisit dan implisit, itu tidak terlalu penting. Yang penting adalah bahwa klien Anda tahu apa yang diharapkan dan dikonfigurasikan dengan tepat untuk melakukannya. Lebih penting lagi, itu harus dikonfigurasi untuk menolak koneksi teks biasa ketika itu mengharapkan koneksi SSL / TLS, apakah itu implisit atau eksplisit .
Perbedaan utama antara SSL / TLS eksplisit dan implisit adalah pada kejelasan pengaturan konfigurasi.
Misalnya, untuk LDAP, jika klien adalah server Apache Httpd ( mod_ldap- sayangnya dokumentasinya juga salah memberi label perbedaan antara SSL dan TLS), Anda dapat menggunakan SSL / TLS implisit dengan menggunakan ldaps://URL (mis. AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) Atau menggunakan SSL / TLS dengan menggunakan parameter tambahan (mis AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS.).
Ada mungkin secara umum risiko sedikit lebih rendah ketika menentukan protokol keamanan dalam skema URL ( https, ldaps, ...) daripada ketika mengharapkan klien untuk mengkonfigurasi pengaturan tambahan untuk mengaktifkan SSL / TLS, karena mereka mungkin lupa. Ini bisa diperdebatkan. Mungkin juga ada masalah dalam kebenaran implementasi satu terhadap yang lain juga (misalnya, saya pikir klien Java LDAP tidak mendukung verifikasi nama host ketika menggunakan ldaps://, ketika seharusnya, sedangkan didukung dengan ldap://+ StartTLS).
Jika ragu, dan kompatibel dengan lebih banyak klien jika memungkinkan, tampaknya tidak ada salahnya untuk menawarkan kedua layanan ketika server mendukungnya (server Anda hanya akan mendengarkan dua port pada saat yang sama). Banyak implementasi server untuk protokol yang dapat digunakan dengan kedua mode akan mendukung keduanya.
Adalah tanggung jawab klien untuk tidak membiarkan dirinya diturunkan ke koneksi teks biasa. Sebagai administrator server, tidak ada yang dapat Anda lakukan secara teknis di sisi Anda untuk mencegah serangan downgrade (selain memerlukan sertifikat klien) Klien harus memeriksa apakah SSL / TLS diaktifkan, apakah itu pada koneksi atau setelah STARTTLSperintah-like. Dengan cara yang sama seperti browser seharusnya tidak membiarkan dirinya dialihkan dari https://ke http://, klien untuk protokol yang mendukung STARTTLS
harus memastikan responsnya positif dan koneksi SSL / TLS diaktifkan sebelum melanjutkan lebih jauh. Seorang penyerang MITM yang aktif dapat dengan mudah menurunkan koneksi.
Misalnya, versi lama Thunderbird memiliki opsi buruk untuk ini yang disebut "Gunakan TLS, jika tersedia" , yang pada dasarnya menyiratkan bahwa jika penyerang MITM mampu mengubah pesan server sehingga tidak mengiklankan dukungan untuk STARTTLS, klien diam-diam membiarkan dirinya diturunkan ke koneksi teks biasa. (Opsi tidak aman ini tidak lagi tersedia di Thunderbird.)