Soru STARTTLS TLS / SSL’den daha az güvenli midir?


Thunderbird'de (ve diğer birçok müşteride de varsayalım) "SSL / TLS" ve "STARTTLS" arasında seçim yapma seçeneğim var.

Anladığım kadarıyla, "STARTTLS" basit kelimeler anlamına gelir "her ikisi de TLS'yi destekliyorsa şifreleyin, aksi halde aktarımı şifrelemeyin". Ve "SSL / TLS" basit kelimeler anlamına gelir "her zaman şifreleyin veya hiç bağlanmayın". Bu doğru mu?

Veya başka bir deyişle:

STARTTLS SSL / TLS'den daha az güvenli midir, çünkü bana haber vermeden düz metne geri dönebilir mi?


43
2017-07-16 19:07


Menşei




Cevaplar:


SMTP için STARTTLS RFC'ye dayanan cevap (RFC 3207):

STARTTLS TLS'den daha az güvenlidir.

Konuşmayı kendim yapmak yerine, RFC'nin kendi başına konuşmasına izin vereceğim; KALIN:

Ortadaki bir adam saldırısı "250" silerek başlatılabilir      STARTTLS "sunucudan yanıt. Bu, müşteriye neden olmaz      TLS oturumu başlatmaya çalışmak. Bir başka ortadaki adam saldırısı      sunucunun STARTTLS özelliğini duyurmasına izin vermek, ancak değiştirmek için      Müşterinin TLS ve sunucunun yanıtını başlatma talebi. İçinde      Bu tür saldırılara karşı savunmak için hem müşteriler hem de sunucular olmak      yapabilmek başarılı bir TLS müzakeresi gerektirecek şekilde yapılandırılmak      mesajlar önce seçilen ana bilgisayarlar için uygun şifre paketi olabilir      başarıyla aktarıldı. Ilave seçenek TLS kullanarak      olası da sağlanmalıdır. Bir uygulama MAYIS AYI sağlamak      Verilen TLS ile iletişim kurmada kullanabilme yeteneği      Daha sonraki bir oturumda kullanılmadığında eş aktarabilir ve uyarı üretebilir.

TLS anlaşması başarısız olursa veya müşteri bir 454 alırsa      Yanıt, müşterinin ne yapacağına karar vermesi gerekiyor. Üç vardır      ana seçenekler: SMTP oturumunun geri kalanı ile devam edin, [...]

Gördüğünüz gibi, RFC'nin kendisi (çok açık bir şekilde değil, açık bir şekilde), müşterilerin güvenli bir bağlantı kurmasını ve güvenli bir bağlantı kurulamadığında kullanıcıları bilgilendirmesini gerektiren bir durum olmadığını belirtir. O açıkça istemcilere sessizce kurma seçeneği sunar Düz metin bağlantıları.


43
2017-12-01 16:43



Sizin noktanız kesinlikle geçerlidir, ancak SMTP (SMTP + "SSL / TLS" nin ilk olarak SSL / TLS'nin kurulduğu) ile ilgili herhangi bir RFC veya resmi belirtimin olmaması nedeniyle, SMTP / SMTPS istemcileri de düz bir bağlantıya geri dönmeye karar verebilir. 465 numaralı bağlantı noktasında SSL / TLS bağlantısı başlatmayı başaramazlarsa, bu yalnızca bir uygulama seçimidir. - Bruno
TLS bağlantıları kurmak için çok sayıda RFC var. Orada hiçbir yerde "düz metin bağlantısına izin ver" seçeneği, RFC'ye uygun bir seçenek olarak mevcut (en azından bu, birçok kişiye haber olurdu). Bu nedenle SMTPS, ayrı bir RFC'nin STARTTLS'den daha güvenli olmasını gerektirmez. - Greg
TLS (RFC 5246 ve öncülleri), PKI (RFC 5280), isim doğrulaması (RFC 6125) ile ilgili RFC'ler vardır, fakat SMTP ve SMTPS resmi olarak AFAIK'te SSL / TLS arasındaki etkileşimi tanımlayacak hiçbir şey yoktur. HTTPS için bir özellik: RFC 2818. Biri "açıkça, sadece SSL / TLS bağlantısını kurabilir" diyebilir, ancak bununla ilgili her şey açık değildir (özellikle kimlik doğrulama yönü, yalnızca son zamanlarda RFC 6125'te resmileştirilmiştir). - Bruno


İki seçenek arasındaki güvenlikte bir fark yoktur.

  • SSL / TLS önce bir SSL / TLS bağlantısı açar, ardından SMTP işlemini başlatır. Bu, halihazırda çalışan bir SSL / TLS SMTP sunucusuna sahip olmayan bir bağlantı noktasında gerçekleşmelidir; Protokollerin yapısı gereği hem düz metin hem de şifrelenmiş bağlantıları ele almak için tek bir port yapılandırmak mümkün değildir.

  • STARTTLS, SMTP işlemini başlatır ve EHLO'ya yanıt olarak TLS'nin diğer ucundan destek arar. İstemci desteklenen komut listesinde STARTTLS görürse, STARTTLS gönderir ve şifreleme için pazarlık yapmaya başlar. Tüm bunlar (ve genellikle) standart SMTP portunda (25), kısmen geriye dönük uyumluluk için olabilir, fakat aynı zamanda hem destekleyici hem de zorunlu olarak gerektirmeyen uç noktalar arasında fırsatçı şifrelemeye olanak sağlar.

Genellikle, SSL / TLS sadece son istemciler ve sunucular arasında kullanılır. STARTTLS, sunucu arası taşımayı güvenli hale getirmek için MTA'lar arasında daha sık kullanılır.

Bu iki uygulama göz önüne alındığında, STARTTLS, kullanıcının veya yöneticinin, bağlantının şifrelenmiş olduğunu varsayıyorsa, ancak şifreleme gerektirecek şekilde yapılandırılmamışsa, güvensiz olarak yorumlanabilir. Bununla birlikte, kullanılan şifreleme SSL / TLS ile tam olarak aynıdır ve bu nedenle bu tür yapılandırma hatasının ötesine geçen bir Man-in-the-Middle saldırısına karşı daha fazla veya daha az savunmasız değildir.


21
2017-07-16 19:40



Bağlantı şifreli ise, hem SSL / TLS hem de STARTTLS aynıdır, evet. Ama istediğim bu değildi. Demek istediğim: Eğer STARTTLS kullanırsam, bağlantımın gerçekten güvenli olup olmadığını nasıl bileceğim (kullanıcı olarak)? SSL / TLS kullanmaya çalışırsam, sunucu desteklemiyorsa bağlanamıyorum, ancak en azından hiçbir şey düz metin olarak gönderilmez. Ancak, STARTTLS düz metne geri dönerse, postam düz metin olarak gönderilmeden bana gönderilir (aslında olmadığımı düşünürken güvende olduğumu düşünmeme neden olur). - Foo Bar
Bu cevabın neden doğru olarak seçildiğini bilmiyorum. Yanlış. Christopher'ın belirttiği gibi, STARTTLS, müşterilere yanlış bir güvenlik duygusu verdiği için TLS'den daha az güvenlidir. - Greg
@greg protokolde bir sorun yok. Hata, rfc'yi takip etmeyen ve bağlantı şifrelenmediğinde kullanıcıyı uyarmayan istemcilerdir. - longneck
@longneck yani ... belki bu semantik bir şeydir, ancak istemciler TLS protokolünü takip edemez ve bir e-posta geçirir, dönem geçirir. Yani bu anlamlı bir fark. - Greg
@Bruno "Eğer müşteri kötü bir şekilde uygulanmışsa, sadece daha az güvenlidir" <= sadece benim için bir anlam ifade ediyorsun. İstemcinin hala bir bağlantı kurarken bağlantı güvenliğini sağlamak için yapabileceği bir şey varsa, o zaman STARTTLS açık TLS'den daha az güvenlidir (bu mümkün değildir). - Greg


Özellikle e-posta için Ocak 2018'de RFC 8314 "Paylaşılan TLS" nin, IMAP, POP3 ve SMTP gönderimleri için STARTTLS mekanizmasının tercihinde kullanılmasını açıkça tavsiye eden bir sürüm yayınlandı.

Özetle, bu not şu anda şunları önermektedir:

  • MUA'lar arasındaki tüm trafik için TLS sürüm 1.2 veya üstü kullanılır     Posta Gönderim Sunucuları ve ayrıca MUA'lar ve Mail Access arasında     Sunucular.
  • MUA'lar ve Posta Servis Sağlayıcıları (MSPs) (a) kullanımından vazgeçirmek     posta erişimi ve posta gönderimi için cleartext protokolleri ve     (b) bu ​​amaçlarla açık metin protokollerinin kullanımını reddetme     en kısa zamanda uygulanabilir.
  • Posta Gönderim Sunucularına ve Posta Erişim Sunucularına Bağlantılar     "Örtülü TLS" kullanılarak yapılan (aşağıda tanımlandığı gibi), tercihe göre     "cleartext" bağlantı noktasına bağlanmak ve TLS'yi kullanarak     STARTTLS komutu veya benzer bir komut.

(vurgu eklenmiştir)


6
2018-02-01 19:38





Cevap, "güvenli" ile ne demek istediğine bağlı.

İlk olarak, özetiniz SSL / TLS ve STARTTLS arasındaki farkı tam olarak yakalamıyor.

  • SSL / TLS ile istemci, kullanmak istediği uygulama protokolüne atanan "SSL portu" na bir TCP bağlantısı açar ve TLS'yi hemen konuşmaya başlar.
  • STARTTLS ile istemci, kullanmak istediği uygulama protokolüyle ilişkili "temiz metin bağlantı noktası" na bir TCP bağlantısı açar, ardından sunucudan "hangi protokol uzantılarını destekliyorsunuz?" Diye soruyor. Sunucu daha sonra bir uzantı listesiyle yanıt verir. Bu uzantılardan biri "STARTTLS" ise, müşteri "tamam, TLS kullanalım" ve iki TLS konuşmaya başlayabilir.

Eğer müşteri TLS gerektirecek şekilde konfigüre edilmişse, iki yaklaşım daha az veya eşit derecede güvenlidir. Ancak, STARTTLS'nin güvenli hale getirmek için nasıl kullanılması gerektiğine dair bazı incelemeler var ve bu ayrıntıların doğru bir şekilde elde edilmesi için STARTTLS uygulamasının uygulanması biraz daha zor.

Diğer taraftan, müşteri TLS kullanılabilir olduğunda TLS'yi kullanacak şekilde yapılandırılmışsa ve TLS kullanılamıyorsa cleartext kullanırsa, istemcinin yapacağı şey ilk olarak protokol tarafından kullanılan SSL portuna bağlanmayı dener. başarısız olur, ardından cleartext bağlantı noktasına bağlanın ve STARTTLS'yi kullanmaya çalışın ve her iki durumda da TLS'nin mevcut olmaması durumunda net metinlere geri dönün. Bir saldırganın SSL port bağlantısının başarısız olmasına neden olması oldukça kolaydır (tek yapmanız gereken bazı iyi zamanlanmış TCP RST paketleri veya SSL portunun bloke edilmesidir). Bir saldırganın STARTTLS görüşmesini yenmesi ve trafiğin net metin olarak kalmasına neden olması biraz daha zor - ama birazcık daha zor. Ve sonra saldırgan sadece e-postanızı okumakla kalmaz, aynı zamanda ileride kullanmak için kullanıcı adınızı / şifrenizi de yakalar.

Bu nedenle, basit cevabı, TLS'yi zaten bildiğiniz bir sunucuya bağlanıyorsanız (e-posta gönderdiğinizde veya e-posta gönderdiğinizde olduğu gibi), SSL / TLS kullanmalısınız. Bağlantıya saldırıya uğrarsanız, bağlantı girişimi başarısız olur, ancak şifreniz ve e-posta adresiniz ele geçirilmeyecektir.

Öte yandan, TLS'yi destekleyip desteklemediğini bilmediğiniz bir hizmete bağlanıyorsanız, STARTTLS marjinal olarak daha iyi olabilir.

STARTTLS icat edildiğinde, "pasif" yalnızca dinleme saldırıları çok yaygındı, saldırganın güvenliği azaltmak için trafiği enjekte ettiği "aktif" saldırılar daha az yaygındı. O zamandan beri 20 yıl içinde, aktif saldırılar daha uygulanabilir ve daha yaygın hale geldi.

Örneğin, bir havaalanında veya başka bir halka açık yerde bir dizüstü bilgisayar kullanmaya çalışıyorsanız ve postanızı orada sağlanan kablosuz bağlantı üzerinden okumaya çalışıyorsanız, bu kablosuz ağın trafiğinizle ne yaptığına dair hiçbir fikriniz yoktur. Wifi ağlarının, istemci uygulamalarınız ve konuşmaya çalıştıkları sunucular arasında kendilerini birbirine bağlayan "proxy'lere" belirli trafik türlerini yönlendirmek çok yaygındır. İstemcinin net metni geri almasını sağlamak için proxy'lerin hem STARTTLS'yi hem de "bir bağlantı noktasını daha sonra deneyin" özelliğini devre dışı bırakması önemsizdir. Evet, bu olur ve bu, trafiğinizin bir ağ tarafından nasıl gizlenebileceğinin sadece bir örneğidir. Ve bu saldırılar üç harfli devlet destekli kurumlarla sınırlı değil, bir yerde halka açık bir yerde saklanan 35 dolarlık bir bilgisayarla bir genç tarafından çekilebilir.


2
2018-02-02 09:29





Evet, temel haklarınız var. Ve evet, STARTTLS kesinlikle daha az güvenli. Bildirimde bulunmadan sadece düz metin olarak yazılması için değil, aynı zamanda ortadaki saldırılara maruz kaldığı için. Bağlantı net olarak başladığından, bir MitM, STARTTLS komutunu çıkarabilir ve şifrelerin oluşmasını engelleyebilir. Ancak, mailservers'ın aktarımların sadece şifrelenmiş bir tünel kurulduktan sonra gerçekleştiğini belirtebileceğine inanıyorum. Böylece bu konuda çalışabilirsiniz.

Öyleyse neden böyle bir şey var? Uyumluluk nedeniyle. Her iki taraf da şifrelemeyi desteklemiyorsa, bağlantının düzgün bir şekilde tamamlanmasını isteyebilirsiniz.


1
2017-07-16 19:20



Yani, STARTTLS yeteneğine sahip bir sunucu da her zaman SSL / TLS yeteneğine sahip olacak, değil mi? Bu yüzden, önce SSL / TLS'yi denemek ve işe yarayıp yaramadığını görmek her zaman daha iyidir. - Foo Bar
@FooBar hayır, biri diğerinin mevcut olduğunu ima etmez. Aslında tamamen farklı kimlik doğrulama alanları ile yapılandırılabilirler. - longneck
Sertifikaları doğrulamadığınız veya zayıf olanları kullanmadığınız sürece STARTTLS, MitM'ye karşı savunmasız değildir. Sertifika hala her zaman olduğu gibi sunulmaya devam ediyor ve müşteri TLS güncellemesinin devam etmeden önce başarılı olmasını gerektirebilir. Bu, SSL / TLS ile aynı durumun aynı olduğunu belirtmekte fayda var. - Falcon Momot
İnsanların sizi neden düşürdüğünü bilmiyorsunuz, bu doğru cevap, STARTTLS TLS'den daha az güvenli ve yanlış bir güvenlik hissi veriyor. ISS'ler sadece şunları yapabilir: arstechnica.com/tech-policy/2014/11/... - Greg
Protokolün kendisi gittikçe, STARTTLS, TLS'den daha az güvenlidir, çünkü kullanıcı uyarı vermeden açık metin iletişimine açıkça izin verir: serverfault.com/a/648282/207987 - Greg


@Greg ile katılıyorum. Bu saldırılar mümkün. Ancak MTA'lar, "fırsatçı TLS" yerine "zorunlu TLS" kullanmak için (MTA'ya bağlı olarak) yapılandırılabilir. Bunun anlamı, e-posta işlemleri için TLS ve sadece TLS'nin kullanılmasıdır (buna ayrıca STARTTLS dahildir). Uzak MTA STARTTLS'yi desteklemiyorsa, e-posta geri döndürülür.


1
2018-04-02 23:47





Hayır o değil Uygulamanız doğru şekilde işlendiğinde daha az güvenlidir.

TLS işlemek için dört yol vardır ve birçok program seçmenize izin verir:

  • TLS yok
  • Özel limanda TLS (sadece TLS'yi dener)
  • Varsa TLS kullanın (Denemeler starttls, başarısız olduğunda şifresiz bir bağlantı kullanır.)
  • Her zaman TLS kullanın (Kullanımlar starttls çalışmazsa ve başarısız olursa)

TLS'nin özel bir bağlantı noktasındaki avantajı, henüz bilmediğiniz bir programı kullandığınızda veya ilk başlangıç ​​sihirbazında hata işleme ayrıntı ayarlarını göstermediğinizde herhangi bir geri dönüş olmadığından emin olmanızdır.

Ancak genel olarak güvenlik, güvenlik hatalarının ele alınmasına bağlıdır. TLS Portundaki TLS de başarısız olduğunda bir program düz metin bağlantı noktasına geçmeye karar verebilir. Ne yapacağını bilmeli ve güvenli ayarları seçmelisin. Programlar güvenli varsayılanları kullanmalıdır.


0
2018-02-02 10:10