SSL ve TLS arasındaki fark


91

Wikipedia'ya göre: http://en.wikipedia.org/wiki/Transport_Layer_Security

TLS, SSL'nin yerini almış gibi görünüyor, ancak çoğu web sitesi hala SSL kullanıyor mu?


4
"çoğu web sitesi hala SSL kullanıyor". İşte protokol desteği ile ilgili iyi bir anket trustworthyinternet.org/ssl-pulse/#chart-protocol-support
Albay Panic

Yanıtlar:


60

Kısacası, TLSv1.0 aşağı yukarı SSLv3.1'dir. Bu soruda ServerFault'ta daha fazla ayrıntı bulabilirsiniz .

Çoğu web sitesi aslında en azından hem SSLv3 hem de TLSv1.0'ı desteklemektedir, çünkü bu çalışmada (Lee, Malkin ve Nahum'un makalesi: SSL / TLS Sunucularının Şifreleme Gücü: Mevcut ve Son Uygulamalar , IMC 2007) ( IETF TLS listesinden elde edilen bağlantı ). % 98'den fazlası TLSv1 + 'i destekler.

Sanırım SSLv3'ün hala kullanımda olmasının nedeni eski destek içindi (günümüzde çoğu tarayıcı TLSv1 ve bazı TLSv1.1 veya hatta TLSv1.2'yi desteklese de). Çok uzun zaman öncesine kadar, bazı dağıtımlarda varsayılan olarak diğerleriyle birlikte SSLv2 (güvenli olmadığı kabul edilir) açıktı.

( Bu soruyu , SSL ile TLS yerine TLS kullanım modeli ile ilgili olsa da ilginç bulabilirsiniz (aslında SSL ile aynı kalıba sahip olabilirsiniz). HTTPS, SSL / TLS kullandığından bu yine de HTTPS için geçerli değildir. bağlantının başından itibaren.)


23

Gönderen http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

90'ların başında, World Wide Web'in başlangıcında, Netscape'teki bazı mühendisler güvenli HTTP istekleri yapmak için bir protokol geliştirdiler ve buldukları şey SSL olarak adlandırıldı. O sırada güvenli protokollerle ilgili görece kıt bilgi birikimi ve Netscape'teki herkesin altında çalıştığı yoğun baskı göz önüne alındığında, çabaları ancak inanılmaz derecede kahramanca görülebilir. Aynı bağ bozumundan bir dizi başka protokolün aksine, SSL'nin sahip olduğu kadar uzun süre dayanması şaşırtıcı. O zamandan beri kesinlikle çok şey öğrendik, ancak protokoller ve API'ler ile ilgili olan şey, geri dönüşün çok az olmasıdır.

SSL protokolünde, SSL 2 (1995) ve SSL 3 (1996) için iki büyük güncelleme yapılmıştır. Bunlar, benimsenmeyi kolaylaştırmak için geriye doğru uyumlu olacak şekilde dikkatlice yapıldı. Ancak geriye dönük uyumluluk, bir güvenlik protokolü için geriye dönük savunmasız anlamına gelebilecek bir kısıtlamadır .

Böylece geriye dönük uyumluluğun kırılmasına karar verildi ve yeni protokol TLS 1.0 (1999) olarak adlandırıldı . (Geriye dönüp baktığımızda, TLS 4 olarak adlandırmak daha açık olabilirdi)

Bu protokol ile SSL 3.0 arasındaki farklar dramatik değildir, ancak TLS 1.0 ve SSL 3.0'ın birlikte çalışmaması için yeterince önemlidir.

TLS iki kez revize edilmiştir, TLS 1.1 (2006) ve TLS 1.2 (2008).

2015 itibariyle, tüm SSL sürümleri bozuk ve güvensiz (POODLE saldırısı) ve tarayıcılar desteği kaldırıyor. TLS 1.0 her yerde bulunur, ancak sitelerin yalnızca % 60'ı , üzücü bir durum olan TLS 1.1 ve 1.2'yi destekler .


Bu şeylerle ilgileniyorsanız, Moxie Marlinspike'ın https://www.youtube.com/watch?v=Z7Wl2FW2TcA adresindeki zekice ve eğlenceli konuşmasını tavsiye ederim.


Bir Usenet haberini hatırlıyorum: comp.sources.unix postası 1980'lerin sonunda Secure Sockets Layer. Netscape'in adından başka yaptığı şeyle herhangi bir ilişkisi olduğundan şüpheliyim.
Marquis of Lorne

11

tls1.0, sslv3.1 anlamına gelir

tls1.1, sslv3.2 anlamına gelir

tls1.2, sslv3.3 anlamına gelir

rfc az önce adını değiştirdi, tls1.0'ın onaltılık kodunun 0x0301 olduğunu, yani sslv3.1 olduğunu görebilirsiniz.


2

TLS, SSL ile geriye dönük uyumluluğu korur ve bu nedenle iletişim protokolü, burada belirtilen sürümlerin herhangi birinde neredeyse aynıdır. SSL v.3, TLS 1.0 ve TLS 1.2 arasındaki iki önemli fark, sözde rasgele işlev (PRF) ve bir simetrik anahtar bloğu oluşturmak için kullanılan HMAC karma işlevidir (SHA, MD5, el sıkışma). Uygulama Verileri şifreleme (sunucu anahtarları + istemci anahtarları + IV). TLS 1.1 ve TLS 1.2 arasındaki en büyük fark, 1.2'nin CBC saldırılarına karşı koruma sağlamak için "açık" IV kullanılmasını gerektirmesidir, ancak bunun için PRF veya protokolde herhangi bir değişiklik gerekmez. TLS 1.2 PRF, şifre paketine özgüdür, bu da PRF'nin anlaşma sırasında müzakere edilebileceği anlamına gelir. SSL başlangıçta Netscape Communications (tarihi) tarafından geliştirilmiş ve daha sonra İnternet Mühendisliği Görev Gücü (IETF, güncel) tarafından sürdürülmüştür. TLS, Ağ Çalışma Grubu tarafından sağlanır. TLS'deki PRF HMAC işlevleri arasındaki farklar şunlardır:

TLS 1.0 ve 1.1

PRF (gizli, etiket, tohum) = P_MD5 (S1, etiket + tohum) XOR P_SHA-1 (S2, etiket + tohum);

TLS 1.2

PRF (gizli, etiket, tohum) = P_hash (gizli, etiket + tohum)


0

"Kırılmamışsa, dokunmayın". SSL3 çoğu senaryoda iyi çalışıyor (Ekim ayında SSL / TLS protokolünde bulunan temel bir kusur vardı, ancak bu bir procol'un kendisinden çok uygulamalarda bir kusurdur), bu nedenle geliştiriciler SSL modüllerini yükseltmek için acele etmezler. TLS, bir dizi yararlı uzantı ve güvenlik algoritması getirir, ancak bunlar kullanışlı bir eklentidir ve bir zorunluluk değildir. Bu nedenle çoğu sunucuda TLS bir seçenek olarak kalır. Hem sunucu hem de istemci destekliyorsa kullanılacaktır.

Güncelleme: '2016 SSL 3'te ve hatta 1.2'ye kadar olan TLS'nin çeşitli saldırılara karşı savunmasız olduğu görülmüştür ve TLS 1.2'ye geçiş önerilir. Sunucuya bağımlı olmalarına rağmen TLS 1.2 uygulamalarına yönelik saldırılar da mevcuttur. TLS 1.3 şu anda geliştirme aşamasındadır. Ve şimdi TLS 1.2 bir zorunluluktur.


2
Hayır, bu bir protokol hatasıdır ve geliştiriciler SSL yığınlarını yükseltmelidir. Bununla birlikte, TLS için olanlara ek olarak SSLv3 için RFC 5746'da yeniden anlaşma uzantısını kullanma yönergeleri vardır .
Bruno

Birini bıçakla öldürürseniz, bu bıçak kusuru değil beyninizin kusurudur. Burada aynı. Protokol tasarlanmadığı şekilde kullanılmışsa, bu protokolün bir kusuru değildir.
Eugene Mayevski'nin Geri Arama

1
Protokol, üstündeki uygulamanın onu mümkün olduğunca normal bir soket olarak ele alacağı şekilde tasarlanmıştır. Yeni uzantı olmadan yeniden anlaşma sorunu, uygulama katmanı tarafından farkındalığı zorlar (ör. HTTP). IETF TLS posta listesinde bu konuyla ilgili bir konu başlığı var: ietf.org/mail-archive/web/tls/current/msg04000.html
Bruno

1
Bazılarının uygulama düzeyinde yapılması gerektiğine katılıyorum, ancak herhangi bir uygulamanın farkında değilim ve protokol bunu dikkate alıyor. Yığınlar genellikle meşru olarak başlattıkları yeniden müzakere ile başa çıkabilir, ancak bir MITM başlatırsa (sorun budur) çok fazla değildir. Bu nedenle IETF TLS grubu bunu TLS düzeyinde düzeltmeyi seçti ve bu yüzden insanlar gerçekten bu uzantıyı açmalı veya yeniden pazarlığı tamamen devre dışı bırakmalı.
Bruno

1
SSL 3.0'da bahsettiğinizden daha temel bir sorun var. Örneğin, CBC dolgu oracle'ı ve ayrıca IV'ün veya önceki kaydın yeniden kullanılması. Birincisi hala TLS'yi rahatsız ediyor, ancak çözülebilirken, ikincisi TLS 1.1'de sabitlendi.
Nikos

0

https://hpbn.co/transport-layer-security-tls/ iyi bir giriş

SSL protokolü başlangıçta Netscape'te, müşterilerin kişisel verilerini korumak için şifreleme ve güvenli bir işlem sağlamak için kimlik doğrulama ve bütünlük garantileri gerektiren Web üzerinde e-ticaret işlem güvenliğini sağlamak için geliştirilmiştir. Bunu başarmak için, SSL protokolü, uygulama katmanında, doğrudan TCP'nin üstünde (Şekil 4-1) uygulandı ve üstündeki protokollerin (HTTP, e-posta, anlık mesajlaşma ve diğerleri) değişmeden çalışmasını sağlarken iletişim güvenliğini sağlarken ağ üzerinden iletişim.

SSL doğru kullanıldığında, üçüncü taraf bir gözlemci yalnızca bağlantı uç noktalarını, şifreleme türünü ve ayrıca gönderilen verilerin sıklığını ve yaklaşık miktarını çıkarabilir, ancak gerçek verilerin hiçbirini okuyamaz veya değiştiremez.

SSL 2.0, protokolün halka açık ilk sürümüydü, ancak keşfedilen bir dizi güvenlik kusuru nedeniyle hızla SSL 3.0 ile değiştirildi. SSL protokolü Netscape'e ait olduğundan, IETF, protokolü standartlaştırmak için bir çaba gösterdi ve sonuçta Ocak 1999'da yayınlanan ve TLS 1.0 olarak bilinen RFC 2246 ortaya çıktı. O zamandan beri IETF, güvenlik açıklarını ele almak ve yeteneklerini genişletmek için protokol üzerinde yinelemeye devam etti: TLS 1.1 (RFC 2246) Nisan 2006'da, TLS 1.2 (RFC 5246) Ağustos 2008'de yayınlandı ve çalışmalar şu anda devam ediyor TLS 1.3'ü tanımlamaya devam ediyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.