TLS'nin aslında SSL'nin daha yeni bir sürümü olduğunu ve genellikle bağlantının güvenli olmayandan güvenliye (genellikle bir STARTTLS komutu aracılığıyla) geçişini desteklediğini biliyorum.
Anlamadığım şey, TLS'nin bir BT Uzmanı için neden önemli olduğu ve neden bir seçim yapsam diğerini seçtiğim. TLS gerçekten daha yeni bir sürüm mü ve eğer öyleyse uyumlu bir protokol mü?
Bir BT Uzmanı Olarak: Hangisini ne zaman kullanırım? Hangisini kullanmam?
Yanıtlar:
Kısa cevap:
SSL, TLS'nin öncüsüdür. SSL, Netscape Communications tarafından geliştirilen, daha sonra IETF kapsamında standartlaştırılan ve TLS olarak yeniden adlandırılan özel bir protokoldür. Kısacası, sürümler şu sırayla verilir: SSLv2, SSLv3, TLSv1.0, TLSv1.1 ve TLSv1.2.
Nispeten geniş çaplı bir inanca zıt olarak, bu, SSL ile farklı bir limanda bir hizmet çalıştırmak zorunda kalmamak ve TLS ile düz metin değişkeniyle aynı limanda devam edebilmekle ilgili değildir. İki yaklaşım için hem SSL hem de TLS kullanılabilir. Bu, bağlantı sırasında SSL / TLS (bazen "gizli SSL / TLS" olarak adlandırılır) ve SSL / TLS arasındaki protokol düzeyinde bir komut verildikten sonra, genellikle STARTTLS(bazen "açık SSL / TLS" olarak adlandırılır) arasındaki farkla ilgilidir. . Anahtar kelime STARTTLS"START", TLS değil. Herhangi bir uygulama protokolü değişiminden önce başlatılmadıysa, uygulama protokolü düzeyinde, SSL / TLS'ye geçiş yapılması gerektiğini bildiren bir mesajdır.
Her iki modun da kullanılması, istemcinin düz metin bağlantısına indirilmeyecek şekilde SSL / TLS'yi bir şekilde beklemesini sağlayacak şekilde yapılandırılması şartıyla eşit olmalıdır.
Daha uzun cevap:
Bildiğim kadarıyla, SSLv1 laboratuvarları asla terk etmedi. SSLv2 ve SSLv3 , Netscape tarafından geliştirilen protokollerdi. SSLv2 bir süre güvensiz olarak kabul edildi, çünkü saldırıların azaltılması eğilimli. SSLv3 dahili (3,0)olarak sürüm numarası olarak kullanır ( ClientHellomesaj içinde ).
TLS, IETF içinde daha açık bir protokol olarak standardizasyonun sonucudur. (Sanırım E. Rescorla'nın kitabında bir yerde okudum, adı belli bir şirket lehine olmamak için tüm katılımcıların aynı derecede mutsuz olacak şekilde seçildiğini düşünüyorum: bu standartlarda oldukça yaygın bir uygulamadır. body.) Geçişin nasıl yapıldığına ilgi duyanlar, SSL-Talk List SSS bölümünü okuyabilir ; Bu belgenin etrafında birden çok kopyası var, ancak çoğu bağlantı ( netscape.comeski) modası geçmiş.
TLS çok benzer mesajlar kullanır ( ortak bir sürümde müzakere etmek mümkün olmasına rağmen protokolleri uyumsuz hale getirmek için yeterince farklı ). TLS 1.0 , 1.1 ve 1.2 ClientHello mesajları kullanarak (3,1), (3,2), (3,3)açık bir şekilde SSL devam gösteren sürüm numarası, gösterir.
Bu cevaptaki protokol farklılıkları hakkında daha fazla detay var .
Hangisini ne zaman kullanırım? Hangisini kullanmam?
Mümkünse, alabileceğiniz en yüksek sürümü kullanın. Uygulamada, bir servis sağlayıcı olarak bu, kullanıcıların bu sürümleri destekleyen istemcilere sahip olmasını gerektirir. Her zaman olduğu gibi, her zaman bir risk değerlendirme çalışmasıdır (uygunsa tercihen bir iş vakası ile desteklenir). Bu söyleniyor, yine de SSLv2 kesti.
Ek olarak, SSL / TLS tarafından sağlanan güvenliğin yalnızca hangi sürümü kullandığınızı değil, aynı zamanda uygun bir konfigürasyonla ilgili olduğunu unutmayın: SSLv3'ü zayıf bir şifrelemeyle (veya anonim / boş şifreleme) şifre paketi. Çok zayıf olarak kabul edilen bazı şifre paketleri, TLS'nin yeni sürümleri tarafından açıkça yasaklanmıştır. Daha fazla ayrıntı istiyorsanız , Java 7 SunJSSE sağlayıcısındaki tablolar (ve dipnotları) ilgi çekici olabilir.
En azından TLS 1.1'i kullanmak tercih edilir, ancak tüm müşteriler henüz maalesef desteklemiyor (örneğin, Java 6). 1.1'in altındaki bir sürüm kullanıldığında , BEAST güvenlik açığının hafifletilmesinde kesinlikle göz atmaya değer .
Genel olarak Eric Rescorla'nın kitabını - SSL ve TLS: Güvenli Sistemler Tasarlama ve İnşa Etme, Addison-Wesley, 2001 ISBN 0-201-61598-3'ü gerçekten daha fazla ayrıntı isteyen kişilere öneririm .
TLS'nin aynı limanı kullanmanıza izin verdiğini söylerken, SSL'nin kullanamayacağını söyleyen bir efsane var. Bu doğru değil (ve bu tartışma için liman birleşmesini bırakacağım ). Ne yazık ki, bu efsane, MS Outlook gibi bazı uygulamaların bazen örtük ve açık SSL / TLS arasında bir seçim yapmak istediklerinde yapılandırma seçeneklerinde SSL ve TLS arasında bir seçenek sunduğundan kullanıcılara yayılmış gibi görünmektedir. (Microsoft'ta SSL / TLS uzmanları var, ancak Outlook kullanıcı arayüzüne dahil değiller.)
Bu karışıklığın olmasının sebebi STARTTLSmoddan kaynaklanıyor. Bazı insanlar bunu STARTTLS= TLS olarak anlamış görünüyor , ancak durum böyle değil. Anahtar kelime STARTTLS"START", TLS değil. Neden bu çağrılmadı STARTSSLya STARTSSLORTLSda bu uzantıların sadece teknik özelliklerinde kullanılan isimleri kullanan IETF içinde belirtildiği için (TLS adının sonunda tek durağan olacağını sanıyorum) sanırım.
Günümüzde, çoğu HTTPS sunucusu TLS ile başa çıkabilir, ancak birkaç yıl önce çoğu insan HTTPS için SSLv3 kullanıyordu. HTTPS (kesinlikle konuşuyor, TLS üzerinden HTTP olarak standartlaştırılmış ) normal olarak TCP bağlantısı üzerine SSL / TLS bağlantısını kurar ve ardından SSL / TLS katmanı üzerinden HTTP mesajını gönderir. Aralarında bir HTTP proxy kullanırken bunun bir istisnası vardır. Bu durumda, istemci HTTP proxy'sine açık bir şekilde bağlanır (tipik olarak 3128 numaralı bağlantı noktasında), daha sonra CONNECTHTTP komutunu verir ve yanıt başarılı olursa, bir mesaj göndererek SSL / TLS anlaşmasını başlatır.ClientHellomesaj. Tüm bunlar, tarayıcı ile proxy arasındaki bağlantı söz konusu olduğunda aynı bağlantı noktasında gerçekleşir (açıkçası proxy ile hedef sunucu arasında değil: aynı makine bile değil). Bu SSLv3 ile sadece iyi çalışıyor. Proxy'nin ardındaki durumlarda çoğumuz bunu en azından TLS 1.0'ı desteklemeyen sunuculara karşı kullanmış olacağız.
Bu açıkça şartnamelerin dışında, ancak pratikte çoğu zaman işe yarıyor. Spesifik olarak, STARTTLS komutunu kullandıktan sonra TLS'ye geçiş (SSL değil) hakkında konuşacağız. Uygulamada, SSL de sıklıkla çalışır (tıpkı "TLS üzerinden HTTP" spesifikasyonu gibi, aynı zamanda TLS yerine SSL kullanmayı da kapsar). Bunu kendin deneyebilirsin. STARTTLS'yi destekleyen bir SMTP veya IMAP sunucunuz olduğunu varsayalım, Thunderbird'ü kullanın, tercihlere gidin, gelişmiş seçenekler, config düzenleyici ve kapatın security.enable_tls. Pek çok sunucu hala bağlantıyı kabul edecektir, çünkü uygulamaları SSL / TLS katmanını genellikle SSL ve TLS'yi aynı şekilde kullanamayacak şekilde ayarlayabilecekleri şekilde bir SSL / TLS kütüphanesine devrettiği için kabul eder. As OpenLDAP SSS koyar, "Mekanizma TLSv1 ile kullanılmak üzere tasarlanırken, çoğu uygulama gerektiğinde SSLv3'e (ve SSLv2) düşecektir. ". Emin değilseniz, Wireshark gibi bir alete bakın.
Çoğu müşteri, güvenli varyantın farklı bir bağlantı noktasında olduğu protokoller için TLS 1.0'ı (en azından) kullanabilir. Açıkçası, HTTPS için TLS 1.0'ı (veya üstü) destekleyen çok sayıda tarayıcı ve web sunucusu var. Benzer şekilde, SMTPS, IMAPS, POPS ve LDAPS de TLS kullanabilir. SSL ile sınırlı değillerdir.
Hangisini ne zaman kullanırım? Hangisini kullanmam?
Açık ve örtük SSL / TLS arasında, gerçekten önemli değil. Önemli olan müşterinizin ne bekleyeceğini bilmesi ve buna göre uygun şekilde yapılandırılmış olmasıdır. Daha da önemlisi, açık veya açık bir SSL / TLS bağlantısı beklerken düz metin bağlantılarını reddetmek üzere yapılandırılmalıdır .
Açık ve kapalı SSL / TLS arasındaki temel fark, yapılandırma ayarlarının netliği olacaktır.
Örneğin, LDAP için, istemci bir Apache Httpd sunucusuysa ( mod_ldap- belgelerinde SSL ile TLS arasındaki farkı yanlış etiketler), bir ldaps://URL kullanarak (örneğin AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) örtük SSL / TLS'yi kullanabilir veya açık SSL / Ekstra bir parametre kullanarak TLS (örneğin AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS).
URL şemasında güvenlik protokolü belirtirken belki genel (biraz daha az bir risk konuşan yoktur https, ldapsonlar unutmak çünkü, SSL / TLS etkinleştirmek için ek bir ayarı yapılandırmak müşteri bekliyor olduğundan daha, ...). Bu tartışılabilir. Birinin diğerine karşı uygulamasının doğruluğu konusunda da sorunlar olabilir (örneğin, Java LDAP istemcisinin kullanması ldaps://gerektiğinde ana bilgisayar adı doğrulamasını desteklemediğini düşünüyorum , oysa ldap://+ StartTLS ile desteklenir ).
Kuşkusuz ve mümkünse daha fazla müşteri ile uyumlu olmak, sunucu desteklediğinde her iki hizmeti de sunmak için bir zarar vermez (sunucunuz aynı anda iki bağlantı noktasını dinler). Her iki modla kullanılabilecek protokoller için birçok sunucu uygulaması her ikisini de destekleyecektir.
Düz metin bağlantısına indirgenmemesine izin vermemek müşterinin sorumluluğundadır. Bir sunucu yöneticisi olarak, düşürme saldırılarını engellemek için teknik açıdan yapabileceğiniz hiçbir şey yoktur (belki de bir müşteri sertifikası istemek dışında). Müşteri, bağlantıda mı yoksa bir STARTTLSbenzeri komuttan mı sonra SSL / TLS'nin etkin olup olmadığını kontrol etmelidir . Kendisini izin vermemeliyiz bir tarayıcıyla aynı şekilde yönlendirilecek https://için http://destek olduğu bir protokol için bir istemci, STARTTLS
emin tepki olumlu ve SSL oldu yapmalıdır / TLS bağlantısı herhangi devam etmeden önce etkinleştirildi. Aktif bir MITM saldırganı her iki bağlantıyı da kolayca düşürebilir.
Örneğin, Thunderbird eski sürümleri "varsa kullanın TLS" Bu adlandırılan için kötü seçeneği vardı , esasen ima olanı bir MITM saldırganın o STARTTLS için destek reklam vermedi böylece sunucu mesajları değiştirmek mümkün olsaydı, istemci sessizce düz bir metin bağlantısına indirgenmesine izin verirdi. (Bu güvensiz seçenek artık Thunderbird'de mevcut değildir.)
TLS, SSL'den daha yeni bir protokoldür (ancak AFAIK, SSL v3 ile uyumludur). Genellikle, endişelenmeniz gereken tek bir fark vardır:
Bir SSL'ed protokolü genellikle ayrı bir bağlantı noktasına sahiptir - örneğin, HTTP için 80 ve HTTPS için (HTTP / SSL) 443. SSL portuna bağlandığınızda, tüm oturum şifrelenir.
TLS, SSL’den daha yenidir ve ayrı bir bağlantı noktası gerektirmez - bunun yerine müşteri tarafından müzakere edilmesi gerekir. Örneğin, 143 numaralı bağlantı noktasında IMAP çalıştırabilir ve hem posta sunucusu hem de müşteri TLS'yi destekliyorsa, istemci bir STARTTLSkomut gönderir ve yalnızca şifrelemeyi etkinleştirir. Bu şekilde, SSL'siz uygulamalarla uyumlu kalırken, yalnızca SSL içeren bir bağlantı noktasına ihtiyacınız yoktur.
Özet:
SSL : Biraz daha yaşlı. Düz ve şifreli bağlantılar için ayrı portlar. SSL portundaki tüm trafik her zaman şifrelenir.
TLS : Hem düz hem de şifreli bağlantılar için tek bağlantı noktası. Şifreleme yalnızca istemci bir STARTTLSkomut verdikten sonra etkinleştirilir .
STARTTLSBazı protokollerde kullanılmasının aynı bağlantıda TLS'ye geçmesine olanak sağlaması, SSL ve TLS arasında bir fark değildir. Teknik olarak SSLv3’e de aynı şekilde geçebilirsiniz.
TLS, yalnızca SSL'nin daha yeni bir sürümüdür. Seçeneğiniz olduğunda TLS kullanın. Daha çok, her zamanki gibi, Wikipedia'da .
Bu Indiana Üniversitesi Bilgi Bankası makalesinden:
SSL, Güvenli Yuva Katmanı anlamına gelir. Netscape bu bilgiyi özel olarak iletmek, mesaj bütünlüğünü sağlamak ve sunucu kimliğini garanti etmek için geliştirmiştir. SSL, veriler üzerinde genel / özel anahtar şifreleme kullanarak çalışır. Genellikle web tarayıcılarında kullanılır, ancak SSL ayrıca e-posta sunucuları veya herhangi bir müşteri-sunucu işlemi ile de kullanılabilir. Örneğin, bazı anlık mesajlaşma sunucuları konuşmaları korumak için SSL kullanır.
TLS, Taşıma Katmanı Güvenliği anlamına gelir. İnternet Mühendisliği Görev Gücü (IETF), TLS'yi SSL'nin halefi olarak yarattı. Genellikle e-posta programlarında bir ayar olarak kullanılır, ancak SSL gibi, TLS'nin herhangi bir istemci-sunucu işleminde rolü olabilir.
İki protokol arasındaki farklar çok küçük ve çok teknik ama farklı standartlar. TLS daha güçlü şifreleme algoritmaları kullanır ve farklı portlarda çalışabilir. Ayrıca, TLS sürüm 1.0, SSL sürüm 3.0 ile birlikte çalışmaz.
TLS, SSL'nin daha yeni bir sürümüdür. Bazı yerlerde bu kelimeler sadece protokollerden başka bir anlama gelse de, lütfen sorunuzu netleştirin.