Thunderbird'de (ve diğer birçok müşteride de varsayıyorum) "SSL / TLS" ve "STARTTLS" arasında seçim yapma seçeneğim var.
Anladığım kadarıyla, "STARTTLS" basit bir deyişle "her iki uç da TLS'yi destekliyorsa şifrele, aksi halde transferi şifrelemeyin " anlamına gelir . Ve "SSL / TLS", "her zaman şifreleyin ya da hiç bağlanmayın" kelimesi anlamına gelir . Bu doğru mu?
Veya başka bir deyişle:
STARTTLS SSL / TLS'den daha az güvenli midir, çünkü bana bildirmeden düz metne geri dönebilir mi?
Yanıtlar:
SMART STARTTLS RFC'ye ( RFC 3207 ) dayanan cevap şudur:
Konuşmayı kendim yapmak yerine, BFC'de vurgulanan dört ilgili bit ile RFC'nin kendisi için konuşmasına izin vereceğim :
Sunucudan "250 STARTTLS" yanıtını silerek ortadaki bir saldırı başlatılabilir. Bu, müşterinin bir TLS oturumu başlatmaya çalışmamasına neden olur. Ortadaki bir diğer saldırı ise, sunucunun STARTTLS özelliğini açıklamasına izin vermek, ancak müşterinin TLS'yi başlatma isteğini ve sunucunun yanıtını değiştirmektir. Her iki istemciler ve sunucular GEREKİR tür saldırılara karşı savunmak amacıyla muktedir mesajlar başarıyla transfer edilebilir önce seçilen ana makineler için uygun bir şifre paketinin başarılı TLS müzakere gerektirecek şekilde yapılandırılacak. Mümkün olduğunda TLS kullanmanın ilave seçeneği de sağlanmalıdır. Bir uygulama MAY TLS'nin belirli bir meslektaş ile iletişimde kullanıldığını ve daha sonraki bir oturumda kullanılmazsa bir uyarı oluşturduğunu kaydetme yeteneği sağlamak.
TLS anlaşması başarısız olursa veya müşteri 454 yanıt alırsa, müşterinin daha sonra ne yapacağına karar vermesi gerekir. Üç ana seçenek var: SMTP oturumunun geri kalanıyla devam edin , [...]
Gördüğünüz gibi, RFC'nin kendisi (çok net değil, ama yeterince net bir şekilde) müşterilerin güvenli bir bağlantı kurmasını ve güvenli bir bağlantı koparsa kullanıcıları bilgilendirmesini gerektiren hiçbir şey olmadığını belirtir. Bu açıkça müşterilerine sessizce kurmak için seçeneği sunar düz metin bağlantıları.
İki seçenek arasında güvenlik açısından 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 SSL / TLS SMTP sunucusu olmayan bir bağlantı noktasında yapılmalıdır; protokollerin doğası gereği hem düz metin hem de şifreli bağlantılar için tek bir bağlantı noktası yapılandırmak mümkün değildir.
STARTTLS, SMTP işlemini başlatır ve EHLO'ya yanıt olarak TLS için diğer uçtan destek arar. Eğer müşteri desteklenen komut listesinde STARTTLS'yi görürse, STARTTLS'yi gönderir ve şifreleme için görüşmeye başlar. Bütün bunlar kısmen de olsa geriye dönük uyumluluk için 25 standart SMTP portunda gerçekleşebilir (ancak genellikle bunu da yapabilir), ancak her ikisini de destekleyen ancak zorunlu olarak gerektirmeyen uç noktalar arasında fırsatçı şifrelemeye izin vermek için de olabilir.
Genellikle, SSL / TLS yalnızca son istemciler ve sunucular arasında kullanılır. STARTTLS, MTA'lar arasında sunucu arası taşımayı güvence altına almak için daha sık kullanılır.
Bu iki uygulama göz önüne alındığında, kullanıcı veya yönetici bağlantının şifreli olduğunu varsayıyorsa, ancak şifreleme gerektirecek şekilde yapılandırılmadıysa, STARTTLS güvensiz olarak yorumlanabilir. Ancak, kullanılan şifreleme, tam olarak SSL / TLS ile aynıdır ve bu nedenle, bu tür bir yapılandırma hatasının ötesinde bir Orta Man saldırısına karşı savunmasız kalır.
Özellikle e-posta için, Ocak 2018’de, RFC 8314 piyasaya sürüldü;
Kısaca, bu not şimdi şunları önermektedir:
- TLS sürüm 1.2 veya daha üstü, MUA'lar ve Posta Gönderme Sunucuları arasındaki ve ayrıca MUA'lar ve Posta Erişim Sunucuları arasındaki tüm trafik için kullanılır.
- MUA'lar ve Posta Servis Sağlayıcıları (MSP'ler) (a) posta erişimi ve posta gönderimi için açık metin protokollerinin kullanılmasını önermez ve (b) bu amaçlar için mümkün olan en kısa sürede açık metin protokollerinin kullanılmasını engeller.
- Posta Gönderme Sunucular ve Posta Erişim Sunucuları yapılan bağlantılar, (aşağıda tanımlandığı şekilde) "Örtülü TLS" kullanılarak yapılabilir tercih için "cleartext" portuna bağlanan ve STARTTLS komutu kullanarak TLS müzakere veya benzer bir komutu.
(vurgu eklendi)
Bu sorunun cevabı bir dereceye kadar "güvenli" ile ne kastettiğinize bağlıdır.
Öncelikle, özetiniz SSL / TLS ve STARTTLS arasındaki farkı tam olarak yakalamıyor.
İstemci TLS gerektirecek şekilde yapılandırılmışsa, iki yaklaşım eşit derecede güvenlidir. Ancak STARTTLS'nin güvenli olması için nasıl kullanılması gerektiği konusunda bazı incelikler vardır ve STARTTLS uygulamasının bu ayrıntıları doğru bulması biraz daha zordur.
Öte yandan, müşteri yalnızca TLS kullanılabilir olduğunda TLS kullanacak şekilde yapılandırılmışsa ve TLS mevcut olmadığında açık metin kullanıyorsa, istemcinin yapabileceği şey ilk önce protokol tarafından kullanılan SSL bağlantı noktasına bağlanmaya çalışmaktır. başarısız olursa, ardından cleartext bağlantı noktasına bağlanın ve STARTTLS kullanmaya çalışın ve TLS her iki durumda da mevcut değilse, cleartext'e geri dönün. Bir saldırganın SSL bağlantı noktası bağlantısının başarısız olmasına neden olması oldukça kolaydır (tek gereken bazı iyi zamanlanmış TCP RST paketleri veya SSL bağlantı noktasını engellemektir). Bir saldırganın STARTTLS anlaşmasını yenmesi ve trafiğin açık metin içinde kalmasına neden olması biraz daha zor - ama sadece biraz -. Ve sonra saldırgan sadece e-postanızı okumakla kalmaz, aynı zamanda ileride kullanmak üzere kullanıcı adınızı / şifrenizi de alır.
Bu yüzden basit cevap, zaten TLS'yi destekleyen bir e-posta sunucusuna bağlanıyorsanız (e-posta gönderirken veya okurken olduğu gibi) SSL / TLS kullanmanız gerektiğidir. Bağlantı saldırıya uğrarsa, bağlantı girişimi başarısız olur, ancak şifreniz ve e-postanızdan ödün verilmez.
Ö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" sadece dinleme saldırıları çok yaygındı, saldırganın güvenliği düşürmek için trafik enjekte ettiği "aktif" saldırıları daha az yaygındı. O zamandan bu yana geçen 20 yıl içerisinde aktif saldırılar daha uygulanabilir ve daha yaygın hale geldi.
Örneğin, bir havaalanında veya halka açık bir yerde bir dizüstü bilgisayar kullanmaya ve orada verilen wifi aracılığıyla postanızı okumaya çalışıyorsanız, bu wifi ağının trafiğinizle ne yaptığı hakkında hiçbir fikriniz yok. Wifi ağlarının, kendilerini müşteri uygulamalarınızla konuşmaya çalıştıkları sunucular arasında araya giren "proxy" lere belirli trafik türlerine yönlendirmesi çok yaygındır. Bu proxy'lerin hem STARTTLS'yi devre dışı bırakması hem de müşterinizin normal metni tekrar geri bırakması için "bir bağlantı noktasından diğerini deneyin" önemsizdir. Evet, bu olur ve trafiğinizin bir ağ tarafından nasıl izlenebileceğinin bir örneğidir. Ve bu tür saldırılar, üç harfli devlet destekli kurumlarla sınırlı değildir,
Evet, temel haklarınız var. Ve evet, STARTTLS kesinlikle daha az güvenlidir. Bilgilendirilmeden yalnızca düz metne geri dönmekle kalmaz, aynı zamanda ortadaki adam saldırılarına maruz kaldığından da başarısız olur. Bağlantı net bir şekilde başladığından, bir MitM STARTTLS komutunu kaldırabilir ve şifrelemenin gerçekleşmesini önleyebilir. Ancak, posta sunucularının aktarımların yalnızca şifreli bir tünel kurulduktan sonra gerçekleşebileceğini belirtebileceğine inanıyorum. Böylece bunun üzerinde çalışabilirsiniz.
Öyleyse neden böyle bir şey var? Uyumluluk nedeniyle. Her iki taraf da şifrelemeyi desteklemiyorsa, yine de bağlantının uygun şekilde tamamlanmasını isteyebilirsiniz.
@Greg ile aynı fikirde. Bu saldırılar mümkün. Ancak MTA'lar (MTA'ya bağlı olarak) "fırsatçı TLS" değil "zorunlu TLS" kullanacak şekilde yapılandırılabilir. Bunun anlamı, e-posta işlemlerinde TLS'nin ve yalnızca TLS'nin (STARTTLS'yi de içerir) kullanılmasıdır. Uzak MTA STARTTLS'yi desteklemiyorsa, e-posta atlanır.
Hayır, uygulamanız doğru bir şekilde işlediğinde, daha az güvenli değildir .
TLS ile başa çıkmak için dört yol vardır ve birçok program seçmenize izin verir:
starttls, başarısız olduğunda şifrelenmemiş bir bağlantı kullanır)starttlsve başarısız olur)TLS'nin özel bir bağlantı noktasındaki avantajı, henüz bilmediğiniz bir programı kullanırken hiçbir zaman geri dönüş olmadığından veya ilk başlangıç sihirbazında hata işleme için ayrıntı ayarlarını göstermediğinden emin olmanızdır.
Ancak genel olarak güvenlik, güvenlik hatalarının ele alınmasına bağlıdır. TLS-Port'taki TLS de başarısız olduğunda bir program düz metin portuna geçmeye karar verebilir. Ne yapacağını bilmeniz ve güvenli ayarları seçmeniz gerekir. Ve programlar güvenli varsayılanları kullanmalıdır.